1 <!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
5 <title>A mechanism for updating Debian Policy documents</title>
7 <name>Manoj Srivastava</name>
8 <email>srivasta@debian.org</email>
10 <version>$Revision: 1.3 $</version>
12 <copyrightsummary>Copyright © 2000 by Manoj Srivastava.
15 You are given permission to redistribute this document
16 and/or modify it under the terms of the GNU General Public
17 License as published by the Free Software Foundation; either
18 version 2, or (at your option) any later version.</p>
20 On Debian GNU/Linux systems, the complete text of the GNU
21 General Public License can be found in
22 <tt>/usr/share/common-licenses/GPL</tt>. </p>
26 <heading>Introduction, and Administrivia</heading>
28 This document documents the current practice followed in updating
29 Debian Policy documents. This mechanism has been designed for
30 dealing with policy changes that are light
31 weight and can be decided upon within the policy group, by
32 near consensus. In most day-to-day cases, the Policy group
33 should and must be able to conduct Policy discussions and
34 amendments without the intervention of the Technical Committee
35 or other Constitutional issues. Only in cases of extreme
36 dispute (formal objections) should the intervention of
37 Constitutional bodies come into play. In any other situation,
38 the Policy group should be able to conduct business
39 unfettered. A consequence of this goal is that formal
40 objections should not be used lightly, else this mechanism
44 It should be noted that the team responsible for the task of
45 updating policy does not act as author or editor of Policy
46 itself, that is the task of the Debian Policy mailing list.
49 <em>In the following, the term developer refers to registered
50 Debian developers.</em>
52 <p>A copy of this document should also be found at <url
53 id="http://master.debian.org/~srivasta/policy/"></p>
56 <heading>Archives and Personnel</heading>
58 <heading>The policy maintainers team</heading>
60 The policy document is maintained by a group of people who have
61 access to the CVS repository for the Policy documents;
62 however, this set of people behave more like maintainers
63 rather than authors/editors. This group does not create
64 policy, nor does it exercise editorial control, Policy is
65 decided "upstream". The group that decides on policy should
66 be the group of developers on the debian-policy mailing
67 list, which is how it was always done; so the group of
68 policy maintainers have no real power over policy.
71 Since the policy maintainers have no special powers, there
72 is no restriction of their participattion the discussion. It
73 is preferable to have at least 4-5 people on the job,
74 perhaps closer to 8, so that policy does not languish when
75 any maintainer goes missing (we do need vacations, you know,
76 once in a while), and since little creative power is vested
77 in the maintainers, we do not need a central control. And
78 the BTS can be used as a record of the action decided upon
79 even if all maintainers are away at some time.
83 <heading>The CVS Repository</heading>
85 There is a repository set up on <tt>cvs.debian.org</tt> for
86 this, and the people on the policy maintainer team have
87 write access to it. The Debian policy mailing list gets
88 copies of all the CVS commit notices.
93 <heading>Procedures and Processes</heading>
96 <heading>Initiating discussions</heading>
98 Unlike before, when the policy editor gathered in issues
99 which, in his view, were candidates for inclusion in policy,
100 any one can raise an issue in the mailing list. It is
101 advisable, but by no means mandatory, that the proposer
102 tries an idea out on the mailing list, which can help flesh
103 out details rapidly, and test the sentiment and the
104 collective wisdom of the list. Discussion may be intiated by
105 any member of the list.
108 Once the proposer is satisfied that the proposal has merit
109 (with or without trying the waters on the list), the
110 proposer should file a <em>wishlist</em> bug against the
111 debian-policy package. This stage can be initiated by any
116 <heading>Creating a proposal</heading>
119 Any Debian developer can create a proposal by retitling the
120 wishlist bug in the BTS to have the subject of the form
121 <strong>"[PROPOSED] ..."</strong> or
122 <strong>"[PROPOSAL] ..."</strong>. (Note: The developer may
123 coalesce these steps into one by directly filing a
124 <em>wishlist</em> bug with the proper subject format).
127 This is the pre-discussion period, when the idea is kicked
128 around, and polished. There is no preset time limit, but at
129 some point, if it is stalled, the bug should be closed. A
130 suggested time period is 6 months, since if the
131 proposal has had no action in that period, it is very likely
132 dead. If six months have actually passed, the bug should be
133 retitled <strong>"[OLD PROPOSAL] ..."</strong>, and have the
134 severity set to fixed. The maintainers shall flush out old
135 proposals after a a sufficiently long period of time has
136 elapsed (certainly more than a year or so after the initial
140 Developers may second the issue by emailing a message
141 containing the text "seconded" to the proposal in the
142 BTS. Only registered Debian developers may second proposals.
146 <heading>Creating an Amendment</heading>
148 When a proposal in the BTS has acquired two seconds (apart
149 from the proposer), it becomes a formal amendment. The bug
150 severity is raised to "normal" and the bug is retitled to
151 <strong>"[AMENDMENT DD/MM/YYYY] ..."</strong>.
154 The rationale behind the requirement for seconders is that
158 Encourage people to test the waters on the policy
159 mailing list, and this could help create an proposal
160 with a better chance of success</p>
164 Prevent frivolous or ill conceived proposals from
165 wasting peoples time (if the proposal does not even
166 convince two developers, surely this is not ready for
167 inclusion in Policy?)</p>
172 The whole discussion process is meant to be lightweight; if
173 you wish the proposals to be amended, talk to the proposer,
174 and get the amendment in. Or else, post an alternative, and
175 let the group decide which one is better.
178 If the process gets very contentious, and needs something
179 like votes on amendments and withdrawal of proposal, then
180 this is not the correct forum for this, and the procedures
181 outlined in the constitution should be followed. Note that
182 only non-technical issues can be resolved using the general
183 resolution protocol; technical issues would hopefully be
184 resolved in the group itself, or the technical committee can
185 be called upon to render a decision.
188 This document is not supposed to supplant the processes
189 outlined in the constitution, nor is it intended to run
195 <heading>Final disposition of the proposal</heading>
197 <heading>An accepted amendment</heading>
199 If the amendment is accepted, the bug is marked
200 forwarded and retitled
201 <strong>"[ACCEPTED DD/MM/YYYY] ..."</strong>.
205 <heading>An amendment that stalls or is rejected</heading>
207 If the amendment is stalls, or otherwise fails to pass, it
208 is retitled as <strong>"[REJECTED DD/MM/YYYY] ..."</strong>
209 and has its severity set to <tt>fixed</tt>.
216 <heading>Deadlines for Tabling Discussions</heading>
218 It has been observed in the past that discussions on the
219 mailing list tend to devolve into endless arguments. In
220 order to get away from the debating society aspect, at the
221 time of the formal proposal, a deadline can be set (probably
222 by the proposer, since they are likely to have an idea how
223 contentious the discussion is likely to be) for ending
224 discussion on the issue, which should rarely be less than 10
225 days, and typically two weeks or so. I hope that a hard
226 minimum period need not be set, and that the proposers would
227 be reasonable, and not set too short or too long a time for
231 If a consensus is reached by the policy group, then the
232 maintainers shall enter the amendment into the Policy
233 document, announce the inclusion in the periodic report, and
234 release a new version.</p>
236 <heading>Extensions to Deadlines?</heading>
238 If a deadline is approaching, and the discussion is almost
239 concluded (in other words, it has not reached an impasse),
240 and the consensus on the policy group is that an extension
241 of a week would resolve the issues better, a one-time
242 extension could be granted. Care should be taken in
243 exercising this option, since abusing this would merely
244 postpone closures. Anything that is still not resolved is
245 too contentious not to be sent to the full set of
246 developers in a general resolution proposal.
251 <heading>Deadlock resolution</heading>
253 Formerly, arriving at a consensus was the only way to amend
254 Policy. That worked well when the Project was small,
255 however, we have apparently grown out of that phase, and even
256 the policy mailing list has grown more fractious than in the
257 days of yore. We now need a formal process of deadlock
258 resolution, and we need to recognize that on non-technical
259 issues a small minority should not always hold up deployment
262 If a consensus is not reached, (or if someone submits a
263 formal objection to the proposal) and the end of the
264 discussion period is near, then one is faced with a dilemma.
267 <heading>Impasse on Technical Issues</heading>
269 On technical issues, popularity is a bad way of arriving
270 at conclusions. Hopefully, the policy group would arrive
271 at a consensus on their own. If that fails to happen, or
272 if there is a formal objection raised on the issue, and
273 the issue is a technical one, then the technical committee
274 may be consulted. This should be a rare occurrence. </p>
277 <heading>Non Technical and Subjective Disagreements</heading>
279 However, if the issue is non-technical and subjective,
280 then a vote of the developers may be taken (USENET voting
281 software should be available all over the place, right?),
282 and a super-majority of 75% is needed to carry the
283 amendment through. Failing the super-majority, the issue
284 should be shelved. It may be re-submitted as a a fresh
285 proposal after a suitable cooling off period (which should
286 be no less than a month, typically three months being
287 desirable, unless there are significant new
288 developments). (Demote bug, if the BTS is being used)</p>
290 If the issue raised is especially contentious, or is
291 deemed to be suitable for review by the full set of
292 developers, then four or more developers can call for a
293 hold on the proposal, and move to send the proposal to the
294 larger developer body as a General
295 Resolution. <strong>Note:</strong> The constitution may
296 have additional requirements for submitting a General
297 Resolution, for example, a minimum number of seconders,