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>$Id: proposal.sgml,v 1.1 1998/08/07 19:22:40 srivasta Exp $</version>
13 This document is copyright 1998 Manoj Srivastava. Anyone is
14 given permission to distribute this under the Freee software
15 foundations General Public Licence, Version 2, or any later
16 version, at your convenience.
21 <heading>Introduction, and adminstrivia</heading>
23 This is a proposal for creating a process through which the
24 Debian Policy documents are to be maintained and updated, it
25 sets forth the processes, and also calls for the creation of a
26 team responsible for the task of updating policy, however,
27 this team does not act as author or editor of Policy it self,
28 that is the task of the Debian Policy mailing list.
31 <heading>Deadline for tabling the discussion</heading>
33 I decided to use the suggested "usual" period of two weeks
34 for this proposal. Therefore, this proposal needs to be
35 acted upon before August the 22nd, 1998.
39 <heading>People Seconding the proposal</heading>
41 Well, since Michael Alan Dorman and Richard Braakman have
42 volunteered to serve on the policy maintainer team, I think
43 they have no objection to being seconds.<enumlist>
45 <p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
48 <p>Richard Braakman <email>dark@xs4all.nl</email></p>
55 <heading>Archives and personnel</heading>
57 <heading>The policy maintainers team</heading>
59 I propose we select/install a group of people who have
60 access to the CVS repository for the Policy documents;
61 however, this set of people behave more like maintainers
62 rather than authors/editors. This group does not create
63 policy, not does it excersice editorial control, Policy is
64 decided "upstream". The group that decides on policy should
65 be the group of developers on the Debian-policy mailing
66 lists, which is how it was always done; so the group of
67 policy maintainers have no real power over policy. Since
68 they would have access to the CVS repository I guess it is
69 desirable that the people so appointed be ``mature'',
70 however that is determined.
73 I think that since the policy maintainers have no special
74 powers, there is no need to restrict their participation in
75 the discussion. We do need to have at least 4-5 people on
76 the job, preferably closer to 8, so that policy does not
77 languish when any maintainer goes missing (we do need
78 vacations, you know, once in a while), and since little
79 creative power is vested in the maintainers, we do not need
80 a central control. And the archives of the list can be used
81 as a record of the action decided upon even if all
82 maintainers are away at some time.
86 <heading>The CVS Repository</heading>
88 There should be a repository set up on
89 <tt>cvs.debian.org</tt> for this, with the people on the
90 policy maintainer team having write access to it.
93 The repository should contain all the packages under the
94 control of the team, and also should have anrea where the
95 weekly status document is kep; once the document is under
96 CVS, it should be a simple matter to script exporting the
97 document out to a place where the web server can serve it,
98 as well as create the weekly posting to
99 <tt>debian-poilcy</tt> and <tt>debian-devel</tt> mailing
100 lists. This document could also be kept under CVS then.</p>
104 <heading>Procedures and processes</heading>
106 <heading>Proposing amendments to the Policy</heading>
108 Unlike before, when the policy editor gathered in issues
109 which, in his view, were candidates for inclusion in policy,
110 I propose that issues are brought up in the policy group,
111 and, if the initial discussion warrants it, any developer,
112 with at least two(?) seconds can formally propose as a
116 The rationale behind the requirement for senconders is that
120 Encourage people to test the waters on the policy
121 mailing list, and this could help create an proposal
122 with a better chance of success</p>
126 Prevent frivoulous or ill concieved proposals from
127 wasting peoples time (If the proposal does not even
128 convince two developers, surely this is not ready for
129 inclusion in Policy?)</p>
134 <heading>Notifications and status reports</heading>
136 Periodically, possibly weekly, a summary of current policy
137 topics can be posted to the Developers mailing list, as
138 well as to the policy mailing list. The list of topics
139 should be posted on the web as well.</p>
141 If the current topic list is kept in CVS, then a simple
142 script could handle both the tasks, and all the
143 maintainers need do is keep the CVS repository up do
144 date. If the Bug tracking system is used, this may be
145 semi-automated too.</p>
147 Amendments to policy that have been accepted by the policy
148 group shall also be part of the notification.</p>
152 <heading>Deadlines for tabling discussions</heading>
154 It has been observed in the past that discussions on the
155 mailing list devolve into endless arguments. In order to get
156 away from the debating society aspect, at the time of the
157 formal proposal,a deadline can be set (probably by the
158 proposer, since they are likely to have an idea how
159 contentious the discussion is likely to be) for ending
160 discussion on the issue, which should rarely be less than 10
161 days, and typically two weeks or so. I hope that a hard
162 minimum period need not be set, and that the proposers would
163 be reasonable, and not set too short or too long a time for
167 If a consensus is reached by the policy group, then the
168 maintianers shall enter the amendment into the Policy
169 document, announce the inclusion in the periodic report, and
170 release a new version.</p>
172 <heading>Extensions to deadlines?</heading>
174 If a deadline is approaching, and the discussion s almost
175 concluded (in other words, it has not reached an impasse),
176 and the consensus on the policy group is that an extension
177 of a week would resolve the issues better, a one-time
178 extention could be granted. Care should be taken in
179 exercising this option, since abusing this would merely
180 postpone closures. </p>
184 <heading>Deadlock resolution</heading>
186 Formerly, arriving at a consensus was the only way to amend
187 Policy. That worked well when the Project was small,
188 however, we have aparently grown out of that phase, and even
189 the policy mailing list has grown more fractious than in the
190 days of yore. We now need a formal process of deadlock
191 resolution, and we need to recognize that on non-technical
192 issues a small minority should not always hold up deployment
195 If a consensus is not reached, (or if someone submits a
196 formal objection to the proposal) and the end of the
197 discussion period is near, then one is faced with a dilemma.
200 <heading>Impasse on technical issues</heading>
202 On technical issues, popularity is a bad way of arriving
203 at conclusions. Hopefully, the policy group would arrive
204 at a consensus on their own. If that fails to happen, or
205 if there is a formal objection raised on the issue, and
206 the issue is a technical one, then the technical committee
207 may be consulted. This should be a rare occurrence. </p>
210 <heading>Non technical and subjective disagreements</heading>
212 However, if the issue is non-technical and subjective,
213 then a vote of the developers may be taken (USENET voting
214 software should be available all over the place, right?);
215 and a super-majority of 75% is needed to carry the
216 amendment through. Failing the super-majority, the issue
217 should be shelved. It may be re-submitted as a a fresh
218 proposal after a suitable cooling off period (which should
219 be no less than a month, typically three months being
220 desirable, unless there are significant new
221 developments). (Demote bug, if the BTS is being used)</p>
225 <heading>Using the bug tracking system</heading>
227 A fascinating sub proposal has been that we use the bug
228 tracking system to track policy amendments in progress. If
229 this is used, we may intiate discussions in the policy group
230 by filing wish-list bugs (note: this should be open to
233 Formal proposals should be treated as normal bugs, and after
234 the discussion period are either closed (when incorporated
235 in policy, or roundly rejected as undesirable), or are
236 demoted to (forwarded?) wish list bugs. I like them being
237 demoted to forwarded status, since the upstream authors (the
238 policy mailing list) has already had a stab at them, and
239 they have been shelved until furhter notice. </p>
241 I think that the Policy is critical enough for the project
242 that any real flaws in the policy be automatically be deemed
243 important bugs, unless they affect release management.</p>