You are given permission to redistribute this document @@ -50,8 +50,46 @@ In the following, the term developer refers to registered Debian developers.
-A copy of this document should also be found at
+ 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. +
++ 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 policy shall not be used as a stick to beat + developers with. +
+ ++ Nor does policy always 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. +
+ +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, @@ -102,7 +140,7 @@ 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.
@@ -133,7 +171,7 @@ dead. If six months have actually passed, the bug should be retitled "[OLD PROPOSAL] ...", 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).
@@ -163,7 +201,7 @@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?)