proposal.sgml

   1 <!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
   2 <debiandoc>
   3   <book>
   4     <titlepag>
   5       <title>PROPOSAL: 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.5 $</version>
  11       <copyright>
  12         <copyrightsummary>Copyright &#169; 1998 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/doc/copyright/GPL</var>'. </p>
  23       </copyright>
  24     </titlepag>
  25     <chapt>
  26       <heading>Introduction, and Administrivia</heading>
  27       <p>
  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.
  34       </p>
  35       <p>A copy of this document should also be found at <url
  36       id="http://master.debian.org/%7Esrivasta/policy/"></p>
  37       <sect>
  38         <heading>Deadline for tabling the discussion</heading>
  39         <p>
  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.
  43         </p>
  44       </sect>
  45       <sect>
  46         <heading>People Seconding the Proposal</heading>
  47         <p>
  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>
  51             <item>
  52               <p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
  53             </item>
  54             <item>
  55               <p>Richard Braakman <email>dark@xs4all.nl</email></p>
  56             </item>
  57           </enumlist>
  58         </p>
  59       </sect>
  60     </chapt>
  61     <chapt>
  62       <heading>Archives and Personnel</heading>
  63       <sect>
  64         <heading>The policy maintainers team</heading>
  65         <p>
  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.
  78         </p>
  79         <p>
  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.
  90         </p>
  91       </sect>
  92       <sect>
  93         <heading>The CVS Repository</heading>
  94         <p>
  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.
  98         </p>
  99         <p>
 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>
 108       </sect>
 109     </chapt>
 110     <chapt>
 111       <heading>Procedures and Processes</heading>
 112       <sect>
 113         <heading>Proposing amendments to the Policy</heading>
 114         <p>
 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
 120           policy amendment.
 121         </p>
 122         <p>
 123           The rationale behind the requirement for seconders is that
 124           it would<enumlist>
 125             <item>
 126               <p>
 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>
 130             </item>
 131             <item>
 132               <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>
 137             </item>
 138           </enumlist>
 139         </p>
 140         <sect1>
 141           <heading>Notifications and Status Reports</heading>
 142           <p>
 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>
 147           <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>
 153           <p>
 154             Amendments to policy that have been accepted by the policy
 155             group shall also be part of the notification.</p>
 156         </sect1>
 157       </sect>
 158       <sect>
 159         <heading>Deadlines for Tabling Discussions</heading>
 160         <p>
 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
 171           discussion.
 172         </p>
 173         <p>
 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>
 178         <sect1>
 179           <heading>Extensions to Deadlines?</heading>
 180           <p>
 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>
 188         </sect1>
 189       </sect>
 190       <sect>
 191         <heading>Deadlock resolution</heading>
 192         <p>
 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
 200           of policy.</p>
 201         <p>
 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.
 205         </p>
 206         <sect1>
 207           <heading>Impasse on Technical Issues</heading>
 208           <p>
 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>
 215         </sect1>
 216         <sect1>
 217           <heading>Non Technical and Subjective Disagreements</heading>
 218           <p>
 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>
 229         </sect1>
 230       </sect>
 231       <sect>
 232         <heading>Using the Bug Tracking System</heading>
 233         <p>
 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
 238           anyone at all)</p>
 239         <p>
 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>
 247         <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>
 251       </sect>
 252     </chapt>
 253   </book>
 254 </debiandoc>