<name>Manoj Srivastava</name>
<email>srivasta@debian.org</email>
</author>
- <version>$Revision: 1.3 $</version>
+ <version>$Revision: 1.7 $</version>
<copyright>
- <copyrightsummary>Copyright © 2000 by Manoj Srivastava.
+ <copyrightsummary>Copyright © 2000 by Manoj Srivastava.
</copyrightsummary>
<p>
You are given permission to redistribute this document
<tt>/usr/share/common-licenses/GPL</tt>. </p>
</copyright>
</titlepag>
+ <toc detail="sect">
<chapt>
<heading>Introduction, and Administrivia</heading>
<p>
<em>In the following, the term developer refers to registered
Debian developers.</em>
</p>
- <p>A copy of this document should also be found at <url
- id="http://master.debian.org/~srivasta/policy/"></p>
+ <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>
+
</chapt>
<chapt>
<heading>Archives and Personnel</heading>
</p>
<p>
Since the policy maintainers have no special powers, there
- is no restriction of their participattion the discussion. It
+ is no restriction of their participation the discussion. It
is preferable to have at least 4-5 people on the job,
perhaps closer to 8, so that policy does not languish when
any maintainer goes missing (we do need vacations, you know,
advisable, but by no means mandatory, that the proposer
tries an idea out on the mailing list, which can help flesh
out details rapidly, and test the sentiment and the
- collective wisdom of the list. Discussion may be intiated by
+ collective wisdom of the list. Discussion may be initiated by
any member of the list.
</p>
<p>
dead. If six months have actually passed, the bug should be
retitled <strong>"[OLD PROPOSAL] ..."</strong>, and have the
severity set to fixed. The maintainers shall flush out old
- proposals after a a sufficiently long period of time has
+ proposals after a sufficiently long period of time has
elapsed (certainly more than a year or so after the initial
proposal).
</p>
<item>
<p>
Prevent frivolous or ill conceived proposals from
- wasting peoples time (if the proposal does not even
+ wasting people's time (if the proposal does not even
convince two developers, surely this is not ready for
inclusion in Policy?)</p>
</item>
</chapt>
</book>
-</debiandoc>
\ No newline at end of file
+</debiandoc>
+<!-- Local variables: -->
+<!-- indent-tabs-mode: t -->
+<!-- End: -->
projects / debian / debian-policy.git / blobdiff