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.9 $</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/share/common-licenses/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 itself,
  33         that is the task of the Debian Policy mailing list.
  34       </p>
  35       <p>
  36         It should also be pointed out that this proposal itself does
  37         not call for the modification of the Policy documents
  38         themselves. I would rather not rush into anything as serious
  39         as modification of the formal policy documents themselves, and
  40         I suspect that we would learn and refine this process in
  41         practice. I would rather that the formal modifications be
  42         deferred until after the kinks of this process have been
  43         worked out.
  44       </p>
  45       <p>
  46         Another thing that bears mentioning is that this proposal is
  47         only for the every day routine functioning of the policy
  48         group. Traditionally, the policy group, under the aegis of the
  49         Policy editor, worked on the basis of a consensus derived in
  50         the group. This proposal merely removes the need of a
  51         dedicated policy editor, and passes the Debian packages that
  52         contain the policy into the hands of a few people who no
  53         longer exercise editorial control, and, paying homage to our
  54         growth, relaxes the requirement for a consensus.
  55       </p>
  56       <p>
  57         This is not supposed to change the way the group works, except
  58         in minor detail. There are some policy changes are light
  59         weight and can be decided upon within the policy group, by
  60         near consensus.  In most day-to-day cases, the Policy group
  61         should and must be able to conduct Policy discussions and
  62         amendments without the intervention of the Technical Committee
  63         or other Constitutional issues.  Only in cases of extreme
  64         dispute (formal objection) should the intervention of
  65         Constitutional bodies come into play. In any other situation,
  66         the Policy group should be able to conduct business
  67         unfettered.  This is the only way we can continue to improve
  68         Debian.
  69       </p>
  70       <p>
  71         <em>In the following, the term developer refers to registered
  72           Debian developers.</em>
  73       </p>
  74       <p>A copy of this document should also be found at <url
  75       id="http://master.debian.org/%7Esrivasta/policy/"></p>
  76       <sect>
  77         <heading>Deadline for tabling the discussion</heading>
  78         <p>
  79           I decided to use the suggested "usual" period of two weeks
  80           for this proposal. Therefore, this proposal needs to be
  81           acted upon before August the 22nd, 1998.
  82         </p>
  83       </sect>
  84       <sect>
  85         <heading>People Seconding the Proposal</heading>
  86         <p>
  87           Well, since Michael Alan Dorman, Phil Hands, and Richard
  88           Braakman have volunteered to serve on the policy maintainer
  89           team, I think they have no objection to being
  90           seconds.
  91           <enumlist>
  92             <item>
  93               <p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
  94             </item>
  95             <item>
  96               <p>Richard Braakman <email>dark@xs4all.nl</email></p>
  97             </item>
  98             <item>
  99               <p>Philip Hands <email>phil@hands.com</email></p>
 100             </item>
 101           </enumlist>
 102         </p>
 103       </sect>
 104     </chapt>
 105     <chapt>
 106       <heading>Archives and Personnel</heading>
 107       <sect>
 108         <heading>The policy maintainers team</heading>
 109         <p>
 110           I propose we select/install a group of people who have
 111           access to the CVS repository for the Policy documents;
 112           however, this set of people behave more like maintainers
 113           rather than authors/editors. This group does not create
 114           policy, nor does it exercise editorial control, Policy is
 115           decided "upstream".  The group that decides on policy should
 116           be the group of developers on the Debian-policy mailing
 117           lists, which is how it was always done; so the group of
 118           policy maintainers have no real power over policy. Since
 119           they would have access to the CVS repository I guess it is
 120           desirable that the people so appointed be ``mature'',
 121           however that is determined.
 122         </p>
 123         <p>
 124           I think that since the policy maintainers have no special
 125           powers, there is no need to restrict their participation in
 126           the discussion. We do need to have at least 4-5 people on
 127           the job, preferably closer to 8, so that policy does not
 128           languish when any maintainer goes missing (we do need
 129           vacations, you know, once in a while), and since little
 130           creative power is vested in the maintainers, we do not need
 131           a central control. And the archives of the list can be used
 132           as a record of the action decided upon even if all
 133           maintainers are away at some time.
 134         </p>
 135       </sect>
 136       <sect>
 137         <heading>The CVS Repository</heading>
 138         <p>
 139           There should be a repository set up on
 140           <tt>cvs.debian.org</tt> for this, with the people on the
 141           policy maintainer team having write access to it.
 142         </p>
 143         <p>
 144           The repository should contain all the packages under the
 145           control of the team, and also should have an area where the
 146           weekly status document is kept; once the document is under
 147           CVS, it should be a simple matter to script exporting the
 148           document out to a place where the web server can serve it,
 149           as well as create the weekly posting to
 150           <tt>debian-policy</tt> and <tt>debian-devel</tt> mailing
 151           lists. This document could also be kept under CVS then.</p>
 152         <p>
 153           If possible, a separate mailing list (<tt>debian-policy-admin</tt>)
 154           maybe created which gets copies of all the CVS commit
 155           notices.
 156         </p>
 157       </sect>
 158     </chapt>
 159     <chapt>
 160       <heading>Procedures and Processes</heading>
 161       <sect>
 162         <heading>Proposing amendments to the Policy</heading>
 163         <p>
 164           Unlike before, when the policy editor gathered in issues
 165           which, in his view, were candidates for inclusion in policy,
 166           I propose that issues are brought up in the policy group,
 167           and, if the initial discussion warrants it, any developer,
 168           with at least two(?) seconds can formally propose as a
 169           policy amendment.
 170         </p>
 171         <p>
 172           The rationale behind the requirement for seconders is that
 173           it would<enumlist>
 174             <item>
 175               <p>
 176                 Encourage people to test the waters on the policy
 177                 mailing list, and this could help create an proposal
 178                 with a better chance of success</p>
 179             </item>
 180             <item>
 181               <p>
 182                 Prevent frivolous or ill conceived proposals from
 183                 wasting peoples time (If the proposal does not even
 184                 convince two developers, surely this is not ready for
 185                 inclusion in Policy?)</p>
 186             </item>
 187           </enumlist>
 188         </p>
 189         <p>
 190           The whole discussion process is meant to be light weight; If
 191           you wish the proposals to be amended, talk to the proposer,
 192           and get the amendment in. Or else, post an alternative, and
 193           let the  group decide which one is better.
 194         </p>
 195         <p>
 196           If the process gets very contentious, and needs something
 197           like votes on amendments and withdrawal of proposal, then
 198           this is not the correct forum for this, and the procedures
 199           outlined in the constitution should be followed. Note that
 200           only non-technical issues can be resolved using the general
 201           resolution protocol; technical issues would hopefully be
 202           resolved in the group itself, or the technical committee can
 203           be called upon to render a decision.
 204         </p>
 205         <p>
 206           This document is not supposed to supplant the processes
 207           outlined in the constitution, nor is it an end run around
 208           them.
 209         </p>
 210         <sect1>
 211           <heading>Notifications and Status Reports</heading>
 212           <p>
 213             Periodically, possibly weekly, a summary of current policy
 214             topics can be posted to the Developers mailing list, as
 215             well as to the policy mailing list. Since the BTS is used
 216             for keeping track of policy amendments, the list of
 217             current amendments shall always be on the web.</p>
 218           <p>
 219             Amendments to policy that have been accepted by the policy
 220             group shall also be part of the notification. (recently
 221             resolved bugs)
 222           </p>
 223         </sect1>
 224       </sect>
 225       <sect>
 226         <heading>Deadlines for Tabling Discussions</heading>
 227         <p>
 228           It has been observed in the past that discussions on the
 229           mailing list devolve into endless arguments. In order to get
 230           away from the debating society aspect, at the time of the
 231           formal proposal, a deadline can be set (probably by the
 232           proposer, since they are likely to have an idea how
 233           contentious the discussion is likely to be) for ending
 234           discussion on the issue, which should rarely be less than 10
 235           days, and typically two weeks or so. I hope that a hard
 236           minimum period need not be set, and that the proposers would
 237           be reasonable, and not set too short or too long a time for
 238           discussion.
 239         </p>
 240         <p>
 241           If a consensus is reached by the policy group, then the
 242           maintainers shall enter the amendment into the Policy
 243           document, announce the inclusion in the periodic report, and
 244           release a new version.</p>
 245         <sect1>
 246           <heading>Extensions to Deadlines?</heading>
 247           <p>
 248             If a deadline is approaching, and the discussion s almost
 249             concluded (in other words, it has not reached an impasse),
 250             and the consensus on the policy group is that an extension
 251             of a week would resolve the issues better, a one-time
 252             extension could be granted. Care should be taken in
 253             exercising this option, since abusing this would merely
 254             postpone closures. Anything that is still not resolved is
 255             too contentious not to be sent to the full set of
 256             developers in a general resolution proposal.
 257           </p>
 258         </sect1>
 259       </sect>
 260       <sect>
 261         <heading>Deadlock resolution</heading>
 262         <p>
 263           Formerly, arriving at a consensus was the only way to amend
 264           Policy. That worked well when the Project was small,
 265           however, we have apparently grown out of that phase, and even
 266           the policy mailing list has grown more fractious than in the
 267           days of yore. We now need a formal process of deadlock
 268           resolution, and we need to recognize that on non-technical
 269           issues a small minority should not always hold up deployment
 270           of policy.</p>
 271         <p>
 272           If a consensus is not reached, (or if someone submits a
 273           formal objection to the proposal) and the end of the
 274           discussion period is near, then one is faced with a dilemma.
 275         </p>
 276         <sect1>
 277           <heading>Impasse on Technical Issues</heading>
 278           <p>
 279             On technical issues, popularity is a bad way of arriving
 280             at conclusions. Hopefully, the policy group would arrive
 281             at a consensus on their own. If that fails to happen, or
 282             if there is a formal objection raised on the issue, and
 283             the issue is a technical one, then the technical committee
 284             may be consulted. This should be a rare occurrence. </p>
 285         </sect1>
 286         <sect1>
 287           <heading>Non Technical and Subjective Disagreements</heading>
 288           <p>
 289             However, if the issue is non-technical and subjective,
 290             then a vote of the developers may be taken (USENET voting
 291             software should be available all over the place, right?);
 292             and a super-majority of 75% is needed to carry the
 293             amendment through. Failing the super-majority, the issue
 294             should be shelved. It may be re-submitted as a a fresh
 295             proposal after a suitable cooling off period (which should
 296             be no less than a month, typically three months being
 297             desirable, unless there are significant new
 298             developments). (Demote bug, if the BTS is being used)</p>
 299           <p>
 300             If the issue raised is especially contentious, or is
 301             deemed to be suitable for review by the full set of
 302             developers, then four or more developers can call for a
 303             hold on the proposal, and move to send the proposal to the
 304             larger developer body as a General
 305             Resolution. <strong>Note:</strong> The constitution may
 306             have additional requirements for submitting a General
 307             Resolution, for example, a minimum number of seconders,
 308             etc.
 309           </p>
 310         </sect1>
 311       </sect>
 312       <sect>
 313         <heading>Using the Bug Tracking System</heading>
 314         <p>
 315           A fascinating sub proposal has been that we use the bug
 316           tracking system to track policy amendments in progress. If
 317           this is used, we may initiate discussions in the policy
 318           group by filing wish-list bugs (note: this should be open to
 319           anyone at all) This simplifies how me manage and track open
 320           amendments and issues.  I think both re-titling and the
 321           severity of the bugs can and should be used.</p>
 322         <p>
 323           <taglist>
 324             <tag>Issue raised</tag>
 325             <item>
 326               <p>
 327                 wishlist bug opened in BTS, with a subject of
 328                 "[PROPOSED] ...". This is the pre discussion period,
 329                 when the idea is kicked around, and polished. There is
 330                 no preset time limit, but at some point, if it is
 331                 stalled, the bug should be closed. Only registered
 332                 Debian developers may formally create proposals.
 333               </p>
 334               <p>
 335                 developers may second the issue by emailing "seconded"
 336                 to the BTS. Only registered Debian developers may
 337                 second proposals.
 338               </p>
 339             </item>
 340             <tag>Amendment</tag>
 341             <item>
 342               <p>
 343                 when a proposed issue becomes a formal amendment (when
 344                 it has acquired the required number of seconds), the
 345                 bug severity is raised to "normal" and the bug is
 346                 retitled to "[AMENDMENT DD/MM/YYY] ...".  Actually it
 347                 might be better to close the proposal and reopen so
 348                 the bug date reflects when the clock starts ticking on
 349                 the bug.
 350               </p>
 351               <p>
 352                 This sets up the table for a discussion period,
 353                 normally 10 days to a month. At the end of the
 354                 discussion period, a proposal is either accepted, or
 355                 rejected.
 356             </item>
 357             <tag>Accepted</tag>
 358             <item>
 359               <p>
 360                 if the amendment is accepted, the bug is marked
 361                 forwarded and retitled "[ACCEPTED DD/MM/YYY]...".
 362               </p>
 363             </item>
 364             <tag>Rejected</tag>
 365             <item>
 366               <p>
 367                 if the amendment is closed, it is retitled as
 368                 "[REJECTED  DD/MM/YYY] ..." and closed
 369               </p>
 370             </item>
 371             <tag>Incorporated</tag>
 372             <item>
 373               <p>
 374                 When the proposal is actually integrated into Policy
 375                 and uploaded and moved into the archive, the bug is
 376                 closed.
 377               </p>
 378             </item>
 379           </taglist>
 380         </p>
 381         <p>
 382           I think that the Policy is critical enough for the project
 383           that any real flaws in the policy be automatically be deemed
 384           important bugs, unless they affect release management.</p>
 385       </sect>
 386     </chapt>
 387   </book>
 388 </debiandoc>