+ <sect>
+ <heading>Guidelines for policy change proposals</heading>
+ <p>
+ Policy does not document all existing practice. It only
+ incorporates a minimal ruleset that is required for systems
+ integration (usually selecting one branch from several
+ equally viable technical options). It is not a best
+ practices document.
+ </p>
+ <p>
+ Policy changes under this procedure also should almost never
+ (unless directed by the tech-ctte, and perhaps the DPL)
+ cause a change that would make a significant chunk of
+ packages instantly buggy; for such changes, it is better to
+ implement a gradual transition plan, allowing for partial
+ upgrades (and perhaps using release goals as
+ motivators). Part of the rationale for this is common sense;
+ a global change, in the past, has taken time, and having
+ either a large number of RC bugs, or ignoring a large number
+ of bugs that would otherwise be RC seems silly; and, anyway,
+ there are concerns that the policy group does not really
+ have the power to change policy drastically. This is the
+ basis of the maxim <em>policy shall not be used as a stick to beat
+ developers with.</em>
+ </p>
+
+ <p>
+ Nor does policy <em>always</em> document only existing
+ practices. What that oft misquoted statement refers to was
+ a part of a larger thesis that is meant to suggest that
+ policy is not the place for testing out design; if a
+ complicated technical proposal is to be made into policy, it
+ should be independently implemented, have all the kinks
+ worked out, and then have that working model be implemented
+ as policy. Having to change policy back and forth while a
+ design is being worked out needs be avoided.
+ </p>
+
+ </sect>
+