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.5 $</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/doc/copyright/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 it self,
33 that is the task of the Debian Policy mailing list.
35 <p>A copy of this document should also be found at <url
36 id="http://master.debian.org/%7Esrivasta/policy/"></p>
38 <heading>Deadline for tabling the discussion</heading>
40 I decided to use the suggested "usual" period of two weeks
41 for this proposal. Therefore, this proposal needs to be
42 acted upon before August the 22nd, 1998.
46 <heading>People Seconding the Proposal</heading>
48 Well, since Michael Alan Dorman and Richard Braakman have
49 volunteered to serve on the policy maintainer team, I think
50 they have no objection to being seconds.<enumlist>
52 <p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
55 <p>Richard Braakman <email>dark@xs4all.nl</email></p>
62 <heading>Archives and Personnel</heading>
64 <heading>The policy maintainers team</heading>
66 I propose we select/install a group of people who have
67 access to the CVS repository for the Policy documents;
68 however, this set of people behave more like maintainers
69 rather than authors/editors. This group does not create
70 policy, not does it exercise editorial control, Policy is
71 decided "upstream". The group that decides on policy should
72 be the group of developers on the Debian-policy mailing
73 lists, which is how it was always done; so the group of
74 policy maintainers have no real power over policy. Since
75 they would have access to the CVS repository I guess it is
76 desirable that the people so appointed be ``mature'',
77 however that is determined.
80 I think that since the policy maintainers have no special
81 powers, there is no need to restrict their participation in
82 the discussion. We do need to have at least 4-5 people on
83 the job, preferably closer to 8, so that policy does not
84 languish when any maintainer goes missing (we do need
85 vacations, you know, once in a while), and since little
86 creative power is vested in the maintainers, we do not need
87 a central control. And the archives of the list can be used
88 as a record of the action decided upon even if all
89 maintainers are away at some time.
93 <heading>The CVS Repository</heading>
95 There should be a repository set up on
96 <tt>cvs.debian.org</tt> for this, with the people on the
97 policy maintainer team having write access to it.
100 The repository should contain all the packages under the
101 control of the team, and also should have an area where the
102 weekly status document is kept; once the document is under
103 CVS, it should be a simple matter to script exporting the
104 document out to a place where the web server can serve it,
105 as well as create the weekly posting to
106 <tt>debian-policy</tt> and <tt>debian-devel</tt> mailing
107 lists. This document could also be kept under CVS then.</p>
111 <heading>Procedures and Processes</heading>
113 <heading>Proposing amendments to the Policy</heading>
115 Unlike before, when the policy editor gathered in issues
116 which, in his view, were candidates for inclusion in policy,
117 I propose that issues are brought up in the policy group,
118 and, if the initial discussion warrants it, any developer,
119 with at least two(?) seconds can formally propose as a
123 The rationale behind the requirement for seconders is that
127 Encourage people to test the waters on the policy
128 mailing list, and this could help create an proposal
129 with a better chance of success</p>
133 Prevent frivolous or ill conceived proposals from
134 wasting peoples time (If the proposal does not even
135 convince two developers, surely this is not ready for
136 inclusion in Policy?)</p>
141 <heading>Notifications and Status Reports</heading>
143 Periodically, possibly weekly, a summary of current policy
144 topics can be posted to the Developers mailing list, as
145 well as to the policy mailing list. The list of topics
146 should be posted on the web as well.</p>
148 If the current topic list is kept in CVS, then a simple
149 script could handle both the tasks, and all the
150 maintainers need do is keep the CVS repository up do
151 date. If the Bug tracking system is used, this may be
152 semi-automated too.</p>
154 Amendments to policy that have been accepted by the policy
155 group shall also be part of the notification.</p>
159 <heading>Deadlines for Tabling Discussions</heading>
161 It has been observed in the past that discussions on the
162 mailing list devolve into endless arguments. In order to get
163 away from the debating society aspect, at the time of the
164 formal proposal,a deadline can be set (probably by the
165 proposer, since they are likely to have an idea how
166 contentious the discussion is likely to be) for ending
167 discussion on the issue, which should rarely be less than 10
168 days, and typically two weeks or so. I hope that a hard
169 minimum period need not be set, and that the proposers would
170 be reasonable, and not set too short or too long a time for
174 If a consensus is reached by the policy group, then the
175 maintainers shall enter the amendment into the Policy
176 document, announce the inclusion in the periodic report, and
177 release a new version.</p>
179 <heading>Extensions to Deadlines?</heading>
181 If a deadline is approaching, and the discussion s almost
182 concluded (in other words, it has not reached an impasse),
183 and the consensus on the policy group is that an extension
184 of a week would resolve the issues better, a one-time
185 extension could be granted. Care should be taken in
186 exercising this option, since abusing this would merely
187 postpone closures. </p>
191 <heading>Deadlock resolution</heading>
193 Formerly, arriving at a consensus was the only way to amend
194 Policy. That worked well when the Project was small,
195 however, we have apparently grown out of that phase, and even
196 the policy mailing list has grown more fractious than in the
197 days of yore. We now need a formal process of deadlock
198 resolution, and we need to recognize that on non-technical
199 issues a small minority should not always hold up deployment
202 If a consensus is not reached, (or if someone submits a
203 formal objection to the proposal) and the end of the
204 discussion period is near, then one is faced with a dilemma.
207 <heading>Impasse on Technical Issues</heading>
209 On technical issues, popularity is a bad way of arriving
210 at conclusions. Hopefully, the policy group would arrive
211 at a consensus on their own. If that fails to happen, or
212 if there is a formal objection raised on the issue, and
213 the issue is a technical one, then the technical committee
214 may be consulted. This should be a rare occurrence. </p>
217 <heading>Non Technical and Subjective Disagreements</heading>
219 However, if the issue is non-technical and subjective,
220 then a vote of the developers may be taken (USENET voting
221 software should be available all over the place, right?);
222 and a super-majority of 75% is needed to carry the
223 amendment through. Failing the super-majority, the issue
224 should be shelved. It may be re-submitted as a a fresh
225 proposal after a suitable cooling off period (which should
226 be no less than a month, typically three months being
227 desirable, unless there are significant new
228 developments). (Demote bug, if the BTS is being used)</p>
232 <heading>Using the Bug Tracking System</heading>
234 A fascinating sub proposal has been that we use the bug
235 tracking system to track policy amendments in progress. If
236 this is used, we may initiate discussions in the policy group
237 by filing wish-list bugs (note: this should be open to
240 Formal proposals should be treated as normal bugs, and after
241 the discussion period are either closed (when incorporated
242 in policy, or roundly rejected as undesirable), or are
243 demoted to (forwarded?) wish list bugs. I like them being
244 demoted to forwarded status, since the upstream authors (the
245 policy mailing list) has already had a stab at them, and
246 they have been shelved until further notice. </p>
248 I think that the Policy is critical enough for the project
249 that any real flaws in the policy be automatically be deemed
250 important bugs, unless they affect release management.</p>