1 <!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
5 <title>PROPOSAL: A mechanism for updating Debian Policy documents</title>
7 <name>Manoj Srivastava</name>
8 <email>srivasta@debian.org</email>
10 <version>$Revision: 1.9 $</version>
12 <copyrightsummary>Copyright © 1998 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 `<var>/usr/share/common-licenses/GPL</var>'. </p>
26 <heading>Introduction, and Administrivia</heading>
28 This is a proposal for creating a process through which the
29 Debian Policy documents are to be maintained and updated, it
30 sets forth the processes, and also calls for the creation of a
31 team responsible for the task of updating policy, however,
32 this team does not act as author or editor of Policy itself,
33 that is the task of the Debian Policy mailing list.
36 It should also be pointed out that this proposal itself does
37 not call for the modification of the Policy documents
38 themselves. I would rather not rush into anything as serious
39 as modification of the formal policy documents themselves, and
40 I suspect that we would learn and refine this process in
41 practice. I would rather that the formal modifications be
42 deferred until after the kinks of this process have been
46 Another thing that bears mentioning is that this proposal is
47 only for the every day routine functioning of the policy
48 group. Traditionally, the policy group, under the aegis of the
49 Policy editor, worked on the basis of a consensus derived in
50 the group. This proposal merely removes the need of a
51 dedicated policy editor, and passes the Debian packages that
52 contain the policy into the hands of a few people who no
53 longer exercise editorial control, and, paying homage to our
54 growth, relaxes the requirement for a consensus.
57 This is not supposed to change the way the group works, except
58 in minor detail. There are some policy changes are light
59 weight and can be decided upon within the policy group, by
60 near consensus. In most day-to-day cases, the Policy group
61 should and must be able to conduct Policy discussions and
62 amendments without the intervention of the Technical Committee
63 or other Constitutional issues. Only in cases of extreme
64 dispute (formal objection) should the intervention of
65 Constitutional bodies come into play. In any other situation,
66 the Policy group should be able to conduct business
67 unfettered. This is the only way we can continue to improve
71 <em>In the following, the term developer refers to registered
72 Debian developers.</em>
74 <p>A copy of this document should also be found at <url
75 id="http://master.debian.org/%7Esrivasta/policy/"></p>
77 <heading>Deadline for tabling the discussion</heading>
79 I decided to use the suggested "usual" period of two weeks
80 for this proposal. Therefore, this proposal needs to be
81 acted upon before August the 22nd, 1998.
85 <heading>People Seconding the Proposal</heading>
87 Well, since Michael Alan Dorman, Phil Hands, and Richard
88 Braakman have volunteered to serve on the policy maintainer
89 team, I think they have no objection to being
93 <p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
96 <p>Richard Braakman <email>dark@xs4all.nl</email></p>
99 <p>Philip Hands <email>phil@hands.com</email></p>
106 <heading>Archives and Personnel</heading>
108 <heading>The policy maintainers team</heading>
110 I propose we select/install a group of people who have
111 access to the CVS repository for the Policy documents;
112 however, this set of people behave more like maintainers
113 rather than authors/editors. This group does not create
114 policy, nor does it exercise editorial control, Policy is
115 decided "upstream". The group that decides on policy should
116 be the group of developers on the Debian-policy mailing
117 lists, which is how it was always done; so the group of
118 policy maintainers have no real power over policy. Since
119 they would have access to the CVS repository I guess it is
120 desirable that the people so appointed be ``mature'',
121 however that is determined.
124 I think that since the policy maintainers have no special
125 powers, there is no need to restrict their participation in
126 the discussion. We do need to have at least 4-5 people on
127 the job, preferably closer to 8, so that policy does not
128 languish when any maintainer goes missing (we do need
129 vacations, you know, once in a while), and since little
130 creative power is vested in the maintainers, we do not need
131 a central control. And the archives of the list can be used
132 as a record of the action decided upon even if all
133 maintainers are away at some time.
137 <heading>The CVS Repository</heading>
139 There should be a repository set up on
140 <tt>cvs.debian.org</tt> for this, with the people on the
141 policy maintainer team having write access to it.
144 The repository should contain all the packages under the
145 control of the team, and also should have an area where the
146 weekly status document is kept; once the document is under
147 CVS, it should be a simple matter to script exporting the
148 document out to a place where the web server can serve it,
149 as well as create the weekly posting to
150 <tt>debian-policy</tt> and <tt>debian-devel</tt> mailing
151 lists. This document could also be kept under CVS then.</p>
153 If possible, a separate mailing list (<tt>debian-policy-admin</tt>)
154 maybe created which gets copies of all the CVS commit
160 <heading>Procedures and Processes</heading>
162 <heading>Proposing amendments to the Policy</heading>
164 Unlike before, when the policy editor gathered in issues
165 which, in his view, were candidates for inclusion in policy,
166 I propose that issues are brought up in the policy group,
167 and, if the initial discussion warrants it, any developer,
168 with at least two(?) seconds can formally propose as a
172 The rationale behind the requirement for seconders is that
176 Encourage people to test the waters on the policy
177 mailing list, and this could help create an proposal
178 with a better chance of success</p>
182 Prevent frivolous or ill conceived proposals from
183 wasting peoples time (If the proposal does not even
184 convince two developers, surely this is not ready for
185 inclusion in Policy?)</p>
190 The whole discussion process is meant to be light weight; If
191 you wish the proposals to be amended, talk to the proposer,
192 and get the amendment in. Or else, post an alternative, and
193 let the group decide which one is better.
196 If the process gets very contentious, and needs something
197 like votes on amendments and withdrawal of proposal, then
198 this is not the correct forum for this, and the procedures
199 outlined in the constitution should be followed. Note that
200 only non-technical issues can be resolved using the general
201 resolution protocol; technical issues would hopefully be
202 resolved in the group itself, or the technical committee can
203 be called upon to render a decision.
206 This document is not supposed to supplant the processes
207 outlined in the constitution, nor is it an end run around
211 <heading>Notifications and Status Reports</heading>
213 Periodically, possibly weekly, a summary of current policy
214 topics can be posted to the Developers mailing list, as
215 well as to the policy mailing list. Since the BTS is used
216 for keeping track of policy amendments, the list of
217 current amendments shall always be on the web.</p>
219 Amendments to policy that have been accepted by the policy
220 group shall also be part of the notification. (recently
226 <heading>Deadlines for Tabling Discussions</heading>
228 It has been observed in the past that discussions on the
229 mailing list devolve into endless arguments. In order to get
230 away from the debating society aspect, at the time of the
231 formal proposal, a deadline can be set (probably by the
232 proposer, since they are likely to have an idea how
233 contentious the discussion is likely to be) for ending
234 discussion on the issue, which should rarely be less than 10
235 days, and typically two weeks or so. I hope that a hard
236 minimum period need not be set, and that the proposers would
237 be reasonable, and not set too short or too long a time for
241 If a consensus is reached by the policy group, then the
242 maintainers shall enter the amendment into the Policy
243 document, announce the inclusion in the periodic report, and
244 release a new version.</p>
246 <heading>Extensions to Deadlines?</heading>
248 If a deadline is approaching, and the discussion s almost
249 concluded (in other words, it has not reached an impasse),
250 and the consensus on the policy group is that an extension
251 of a week would resolve the issues better, a one-time
252 extension could be granted. Care should be taken in
253 exercising this option, since abusing this would merely
254 postpone closures. Anything that is still not resolved is
255 too contentious not to be sent to the full set of
256 developers in a general resolution proposal.
261 <heading>Deadlock resolution</heading>
263 Formerly, arriving at a consensus was the only way to amend
264 Policy. That worked well when the Project was small,
265 however, we have apparently grown out of that phase, and even
266 the policy mailing list has grown more fractious than in the
267 days of yore. We now need a formal process of deadlock
268 resolution, and we need to recognize that on non-technical
269 issues a small minority should not always hold up deployment
272 If a consensus is not reached, (or if someone submits a
273 formal objection to the proposal) and the end of the
274 discussion period is near, then one is faced with a dilemma.
277 <heading>Impasse on Technical Issues</heading>
279 On technical issues, popularity is a bad way of arriving
280 at conclusions. Hopefully, the policy group would arrive
281 at a consensus on their own. If that fails to happen, or
282 if there is a formal objection raised on the issue, and
283 the issue is a technical one, then the technical committee
284 may be consulted. This should be a rare occurrence. </p>
287 <heading>Non Technical and Subjective Disagreements</heading>
289 However, if the issue is non-technical and subjective,
290 then a vote of the developers may be taken (USENET voting
291 software should be available all over the place, right?);
292 and a super-majority of 75% is needed to carry the
293 amendment through. Failing the super-majority, the issue
294 should be shelved. It may be re-submitted as a a fresh
295 proposal after a suitable cooling off period (which should
296 be no less than a month, typically three months being
297 desirable, unless there are significant new
298 developments). (Demote bug, if the BTS is being used)</p>
300 If the issue raised is especially contentious, or is
301 deemed to be suitable for review by the full set of
302 developers, then four or more developers can call for a
303 hold on the proposal, and move to send the proposal to the
304 larger developer body as a General
305 Resolution. <strong>Note:</strong> The constitution may
306 have additional requirements for submitting a General
307 Resolution, for example, a minimum number of seconders,
313 <heading>Using the Bug Tracking System</heading>
315 A fascinating sub proposal has been that we use the bug
316 tracking system to track policy amendments in progress. If
317 this is used, we may initiate discussions in the policy
318 group by filing wish-list bugs (note: this should be open to
319 anyone at all) This simplifies how me manage and track open
320 amendments and issues. I think both re-titling and the
321 severity of the bugs can and should be used.</p>
324 <tag>Issue raised</tag>
327 wishlist bug opened in BTS, with a subject of
328 "[PROPOSED] ...". This is the pre discussion period,
329 when the idea is kicked around, and polished. There is
330 no preset time limit, but at some point, if it is
331 stalled, the bug should be closed. Only registered
332 Debian developers may formally create proposals.
335 developers may second the issue by emailing "seconded"
336 to the BTS. Only registered Debian developers may
343 when a proposed issue becomes a formal amendment (when
344 it has acquired the required number of seconds), the
345 bug severity is raised to "normal" and the bug is
346 retitled to "[AMENDMENT DD/MM/YYY] ...". Actually it
347 might be better to close the proposal and reopen so
348 the bug date reflects when the clock starts ticking on
352 This sets up the table for a discussion period,
353 normally 10 days to a month. At the end of the
354 discussion period, a proposal is either accepted, or
360 if the amendment is accepted, the bug is marked
361 forwarded and retitled "[ACCEPTED DD/MM/YYY]...".
367 if the amendment is closed, it is retitled as
368 "[REJECTED DD/MM/YYY] ..." and closed
371 <tag>Incorporated</tag>
374 When the proposal is actually integrated into Policy
375 and uploaded and moved into the archive, the bug is
382 I think that the Policy is critical enough for the project
383 that any real flaws in the policy be automatically be deemed
384 important bugs, unless they affect release management.</p>