]> git.donarmstrong.com Git - debian/debian-policy.git/blob - policy-process.sgml
Synchronized with patch 69 from Manojs tree
[debian/debian-policy.git] / policy-process.sgml
1 <!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
2 <debiandoc>
3   <book>
4     <titlepag>
5       <title>A mechanism for updating Debian Policy documents</title>
6       <author>
7         <name>Manoj Srivastava</name>
8         <email>srivasta@debian.org</email>
9       </author>
10       <version>$Revision: 1.1 $</version>
11       <copyright>
12         <copyrightsummary>Copyright &#169; 2000 by Manoj Srivastava. 
13         </copyrightsummary>
14         <p>
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>
19         <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>
23       </copyright>
24     </titlepag>
25     <chapt>
26       <heading>Introduction, and Administrivia</heading>
27       <p>
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
41         shall be ineffective.
42       </p>
43       <p>
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.
47       </p>
48       <p>
49         <em>In the following, the term developer refers to registered
50           Debian developers.</em>
51       </p>
52       <p>A copy of this document should also be found at <url
53       id="http://master.debian.org/%7Esrivasta/policy/"></p>      
54     </chapt>
55     <chapt>
56       <heading>Archives and Personnel</heading>
57       <sect>
58         <heading>The policy maintainers team</heading>
59         <p>
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           lists, which is how it was always done; so the group of
68           policy maintainers have no real power over policy.
69         </p>
70         <p>
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 atleast 4-5 people on the job,
74           perhapscloser 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.
80         </p>
81       </sect>
82       <sect>
83         <heading>The CVS Repository</heading>
84         <p>
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
89         </p>
90       </sect>
91     </chapt>
92     <chapt>
93       <heading>Procedures and Processes</heading>
94
95       <sect>
96         <heading>Initiating discussions</heading>
97         <p>
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. 
106         </p>
107         <p>
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
112           member of the list.
113         </p>
114       </sect>
115       <sect>
116         <heading>Creating a proposal</heading>
117
118         <p>
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>. (Note: The developer may
122           coalesce these steps into one by directly filing a
123           <em>wishlist</em> bug with the proper seubject format).
124         </p>
125         <p>
126           This is the pre discussion period, when the idea is kicked
127           around, and polished. There is no preset time limit, but at
128           some point, if it is stalled, the bug should be closed. A
129           suggested time period is 6 months, since if the
130           proposal has had no action in that period, it is very likely
131           dead. If six months have actually passed, the bug should be
132           retitled <strong>"[OLD PROPOSAL] ..."</strong>, and have the
133           severity set to fixed. The maintianers shall flush out old
134           proposal after a a suuficiently long period of time
135           (cetainly more than a year or so). 
136         </p>
137         <p>
138           developers may second the issue by emailing "seconded"
139           to the BTS. Only registered Debian developers may
140           second proposals. 
141         </p>
142       </sect>
143       <sect>
144         <heading>Creating an Amendment</heading>
145         <p>
146           When a proposal in the BTS has acquired two seconds (apart
147           from the proposer), it becomes a formal amendment. The bug
148           severity is raised to "normal" and the bug is retitled to
149           <strong>"[AMENDMENT DD/MM/YYY] ..."</strong>.  
150         </p>
151         <p>
152           The rationale behind the requirement for seconders is that
153           it would<enumlist>
154             <item>
155               <p>
156                 Encourage people to test the waters on the policy
157                 mailing list, and this could help create an proposal
158                 with a better chance of success</p>
159             </item>
160             <item>
161               <p>
162                 Prevent frivolous or ill conceived proposals from
163                 wasting peoples time (If the proposal does not even
164                 convince two developers, surely this is not ready for
165                 inclusion in Policy?)</p>
166             </item>
167           </enumlist>
168         </p>
169         <p>
170           The whole discussion process is meant to be light weight; If
171           you wish the proposals to be amended, talk to the proposer,
172           and get the amendment in. Or else, post an alternative, and
173           let the  group decide which one is better.
174         </p>
175         <p>
176           If the process gets very contentious, and needs something
177           like votes on amendments and withdrawal of proposal, then
178           this is not the correct forum for this, and the procedures
179           outlined in the constitution should be followed. Note that
180           only non-technical issues can be resolved using the general
181           resolution protocol; technical issues would hopefully be
182           resolved in the group itself, or the technical committee can
183           be called upon to render a decision.
184         </p>
185         <p>
186           This document is not supposed to supplant the processes
187           outlined in the constitution, nor is it an end run around
188           them.
189         </p>
190       </sect>
191
192       <sect>
193         <heading>Final disposition of the proposal</heading>
194         <sect1>
195           <heading>An accepted amendment</heading>
196           <p>
197             if the amendment is accepted, the bug is marked
198             forwarded and retitled <strong>"[ACCEPTED DD/MM/YYY]..."</strong>.
199           </p>
200         </sect1>
201         <sect1>
202           <heading>An amendment that stalls or is rejected</heading>
203           <p>
204             if the amendment is stalls, or otherwise fails to pass, it
205             is retitled as <strong>"[REJECTED DD/MM/YYY] ..."</strong>
206             and has its severity set to <tt>fixed</tt>. 
207           </p>
208         </sect1>
209       </sect>
210
211
212       <sect>
213         <heading>Deadlines for Tabling Discussions</heading>
214         <p>
215           It has been observed in the past that discussions on the
216           mailing list devolve into endless arguments. In order to get
217           away from the debating society aspect, at the time of the
218           formal proposal, a deadline can be set (probably by the
219           proposer, since they are likely to have an idea how
220           contentious the discussion is likely to be) for ending
221           discussion on the issue, which should rarely be less than 10
222           days, and typically two weeks or so. I hope that a hard
223           minimum period need not be set, and that the proposers would
224           be reasonable, and not set too short or too long a time for
225           discussion.
226         </p>
227         <p>
228           If a consensus is reached by the policy group, then the
229           maintainers shall enter the amendment into the Policy
230           document, announce the inclusion in the periodic report, and
231           release a new version.</p>
232         <sect1>
233           <heading>Extensions to Deadlines?</heading>
234           <p>
235             If a deadline is approaching, and the discussion s almost
236             concluded (in other words, it has not reached an impasse),
237             and the consensus on the policy group is that an extension
238             of a week would resolve the issues better, a one-time
239             extension could be granted. Care should be taken in
240             exercising this option, since abusing this would merely
241             postpone closures. Anything that is still not resolved is
242             too contentious not to be sent to the full set of
243             developers in a general resolution proposal.
244           </p>
245         </sect1>
246       </sect>
247       <sect>
248         <heading>Deadlock resolution</heading>
249         <p>
250           Formerly, arriving at a consensus was the only way to amend
251           Policy. That worked well when the Project was small,
252           however, we have apparently grown out of that phase, and even
253           the policy mailing list has grown more fractious than in the
254           days of yore. We now need a formal process of deadlock
255           resolution, and we need to recognize that on non-technical
256           issues a small minority should not always hold up deployment
257           of policy.</p>
258         <p>
259           If a consensus is not reached, (or if someone submits a
260           formal objection to the proposal) and the end of the
261           discussion period is near, then one is faced with a dilemma.
262         </p>
263         <sect1>
264           <heading>Impasse on Technical Issues</heading>
265           <p>
266             On technical issues, popularity is a bad way of arriving
267             at conclusions. Hopefully, the policy group would arrive
268             at a consensus on their own. If that fails to happen, or
269             if there is a formal objection raised on the issue, and
270             the issue is a technical one, then the technical committee
271             may be consulted. This should be a rare occurrence. </p>
272         </sect1>
273         <sect1>
274           <heading>Non Technical and Subjective Disagreements</heading>
275           <p>
276             However, if the issue is non-technical and subjective,
277             then a vote of the developers may be taken (USENET voting
278             software should be available all over the place, right?);
279             and a super-majority of 75% is needed to carry the
280             amendment through. Failing the super-majority, the issue
281             should be shelved. It may be re-submitted as a a fresh
282             proposal after a suitable cooling off period (which should
283             be no less than a month, typically three months being
284             desirable, unless there are significant new
285             developments). (Demote bug, if the BTS is being used)</p>
286           <p>
287             If the issue raised is especially contentious, or is
288             deemed to be suitable for review by the full set of
289             developers, then four or more developers can call for a
290             hold on the proposal, and move to send the proposal to the
291             larger developer body as a General
292             Resolution. <strong>Note:</strong> The constitution may
293             have additional requirements for submitting a General
294             Resolution, for example, a minimum number of seconders,
295             etc.
296           </p>
297         </sect1>
298       </sect>
299     </chapt>
300
301   </book>
302 </debiandoc>