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.3 $</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           <tt>/usr/share/common-licenses/GPL</tt>. </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/~srivasta/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           list, 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 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.
  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> 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).
 125         </p>
 126         <p>
 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
 137           proposal).
 138         </p>
 139         <p>
 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.
 143         </p>
 144       </sect>
 145       <sect>
 146         <heading>Creating an Amendment</heading>
 147         <p>
 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>.
 152         </p>
 153         <p>
 154           The rationale behind the requirement for seconders is that
 155           it would<enumlist>
 156             <item>
 157               <p>
 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>
 161             </item>
 162             <item>
 163               <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>
 168             </item>
 169           </enumlist>
 170         </p>
 171         <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.
 176         </p>
 177         <p>
 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.
 186         </p>
 187         <p>
 188           This document is not supposed to supplant the processes
 189           outlined in the constitution, nor is it intended to run
 190           around them.
 191         </p>
 192       </sect>
 193
 194       <sect>
 195         <heading>Final disposition of the proposal</heading>
 196         <sect1>
 197           <heading>An accepted amendment</heading>
 198           <p>
 199             If the amendment is accepted, the bug is marked
 200             forwarded and retitled
 201             <strong>"[ACCEPTED DD/MM/YYYY] ..."</strong>.
 202           </p>
 203         </sect1>
 204         <sect1>
 205           <heading>An amendment that stalls or is rejected</heading>
 206           <p>
 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>.
 210           </p>
 211         </sect1>
 212       </sect>
 213
 214
 215       <sect>
 216         <heading>Deadlines for Tabling Discussions</heading>
 217         <p>
 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
 228           discussion.
 229         </p>
 230         <p>
 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>
 235         <sect1>
 236           <heading>Extensions to Deadlines?</heading>
 237           <p>
 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.
 247           </p>
 248         </sect1>
 249       </sect>
 250       <sect>
 251         <heading>Deadlock resolution</heading>
 252         <p>
 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
 260           of policy.</p>
 261         <p>
 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.
 265         </p>
 266         <sect1>
 267           <heading>Impasse on Technical Issues</heading>
 268           <p>
 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>
 275         </sect1>
 276         <sect1>
 277           <heading>Non Technical and Subjective Disagreements</heading>
 278           <p>
 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>
 289           <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,
 298             etc.
 299           </p>
 300         </sect1>
 301       </sect>
 302     </chapt>
 303
 304   </book>
 305 </debiandoc>