A mechanism for updating Debian Policy documents ------------------------------------------------ Manoj Srivastava $Revision: 1.3 $ ------------------------------------------------------------------------------- Copyright Notice ---------------- Copyright © 2000 by Manoj Srivastava. You are given permission to redistribute this document and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. ------------------------------------------------------------------------------- 1. Introduction, and Administrivia ---------------------------------- This document documents the current practice followed in updating Debian Policy documents. This mechanism has been designed for dealing with policy changes that are light weight and can be decided upon within the policy group, by near consensus. In most day-to-day cases, the Policy group should and must be able to conduct Policy discussions and amendments without the intervention of the Technical Committee or other Constitutional issues. Only in cases of extreme dispute (formal objections) should the intervention of Constitutional bodies come into play. In any other situation, the Policy group should be able to conduct business unfettered. A consequence of this goal is that formal objections should not be used lightly, else this mechanism shall be ineffective. It should be noted that the team responsible for the task of updating policy does not act as author or editor of Policy itself, that is the task of the Debian Policy mailing list. _In the following, the term developer refers to registered Debian developers._ A copy of this document should also be found at http://master.debian.org/~srivasta/policy/ ------------------------------------------------------------------------------- 2. Archives and Personnel ------------------------- 2.1. The policy maintainers team -------------------------------- The policy document is maintained by a group of people who have access to the CVS repository for the Policy documents; however, this set of people behave more like maintainers rather than authors/editors. This group does not create policy, nor does it exercise editorial control, Policy is decided "upstream". The group that decides on policy should be the group of developers on the debian-policy mailing list, which is how it was always done; so the group of policy maintainers have no real power over policy. Since the policy maintainers have no special powers, there is no restriction of their participattion the discussion. It is preferable to have at least 4-5 people on the job, perhaps closer to 8, so that policy does not languish when any maintainer goes missing (we do need vacations, you know, once in a while), and since little creative power is vested in the maintainers, we do not need a central control. And the BTS can be used as a record of the action decided upon even if all maintainers are away at some time. 2.2. The CVS Repository ----------------------- There is a repository set up on `cvs.debian.org' for this, and the people on the policy maintainer team have write access to it. The Debian policy mailing list gets copies of all the CVS commit notices. ------------------------------------------------------------------------------- 3. Procedures and Processes --------------------------- 3.1. Initiating discussions --------------------------- Unlike before, when the policy editor gathered in issues which, in his view, were candidates for inclusion in policy, any one can raise an issue in the mailing list. It is advisable, but by no means mandatory, that the proposer tries an idea out on the mailing list, which can help flesh out details rapidly, and test the sentiment and the collective wisdom of the list. Discussion may be intiated by any member of the list. Once the proposer is satisfied that the proposal has merit (with or without trying the waters on the list), the proposer should file a _wishlist_ bug against the debian-policy package. This stage can be initiated by any member of the list. 3.2. Creating a proposal ------------------------ Any Debian developer can create a proposal by retitling the wishlist bug in the BTS to have the subject of the form _"[PROPOSED] ..."_ or _"[PROPOSAL] ..."_. (Note: The developer may coalesce these steps into one by directly filing a _wishlist_ bug with the proper subject format). This is the pre-discussion period, when the idea is kicked around, and polished. There is no preset time limit, but at some point, if it is stalled, the bug should be closed. A suggested time period is 6 months, since if the proposal has had no action in that period, it is very likely dead. If six months have actually passed, the bug should be retitled _"[OLD PROPOSAL] ..."_, and have the severity set to fixed. The maintainers shall flush out old proposals after a a sufficiently long period of time has elapsed (certainly more than a year or so after the initial proposal). Developers may second the issue by emailing a message containing the text "seconded" to the proposal in the BTS. Only registered Debian developers may second proposals. 3.3. Creating an Amendment -------------------------- When a proposal in the BTS has acquired two seconds (apart from the proposer), it becomes a formal amendment. The bug severity is raised to "normal" and the bug is retitled to _"[AMENDMENT DD/MM/YYYY] ..."_. The rationale behind the requirement for seconders is that it would 1. Encourage people to test the waters on the policy mailing list, and this could help create an proposal with a better chance of success 2. Prevent frivolous or ill conceived proposals from wasting peoples time (if the proposal does not even convince two developers, surely this is not ready for inclusion in Policy?) The whole discussion process is meant to be lightweight; if you wish the proposals to be amended, talk to the proposer, and get the amendment in. Or else, post an alternative, and let the group decide which one is better. If the process gets very contentious, and needs something like votes on amendments and withdrawal of proposal, then this is not the correct forum for this, and the procedures outlined in the constitution should be followed. Note that only non-technical issues can be resolved using the general resolution protocol; technical issues would hopefully be resolved in the group itself, or the technical committee can be called upon to render a decision. This document is not supposed to supplant the processes outlined in the constitution, nor is it intended to run around them. 3.4. Final disposition of the proposal -------------------------------------- 3.4.1. An accepted amendment ---------------------------- If the amendment is accepted, the bug is marked forwarded and retitled _"[ACCEPTED DD/MM/YYYY] ..."_. 3.4.2. An amendment that stalls or is rejected ---------------------------------------------- If the amendment is stalls, or otherwise fails to pass, it is retitled as _"[REJECTED DD/MM/YYYY] ..."_ and has its severity set to `fixed'. 3.5. Deadlines for Tabling Discussions -------------------------------------- It has been observed in the past that discussions on the mailing list tend to devolve into endless arguments. In order to get away from the debating society aspect, at the time of the formal proposal, a deadline can be set (probably by the proposer, since they are likely to have an idea how contentious the discussion is likely to be) for ending discussion on the issue, which should rarely be less than 10 days, and typically two weeks or so. I hope that a hard minimum period need not be set, and that the proposers would be reasonable, and not set too short or too long a time for discussion. If a consensus is reached by the policy group, then the maintainers shall enter the amendment into the Policy document, announce the inclusion in the periodic report, and release a new version. 3.5.1. Extensions to Deadlines? ------------------------------- If a deadline is approaching, and the discussion is almost concluded (in other words, it has not reached an impasse), and the consensus on the policy group is that an extension of a week would resolve the issues better, a one-time extension could be granted. Care should be taken in exercising this option, since abusing this would merely postpone closures. Anything that is still not resolved is too contentious not to be sent to the full set of developers in a general resolution proposal. 3.6. Deadlock resolution ------------------------ Formerly, arriving at a consensus was the only way to amend Policy. That worked well when the Project was small, however, we have apparently grown out of that phase, and even the policy mailing list has grown more fractious than in the days of yore. We now need a formal process of deadlock resolution, and we need to recognize that on non-technical issues a small minority should not always hold up deployment of policy. If a consensus is not reached, (or if someone submits a formal objection to the proposal) and the end of the discussion period is near, then one is faced with a dilemma. 3.6.1. Impasse on Technical Issues ---------------------------------- On technical issues, popularity is a bad way of arriving at conclusions. Hopefully, the policy group would arrive at a consensus on their own. If that fails to happen, or if there is a formal objection raised on the issue, and the issue is a technical one, then the technical committee may be consulted. This should be a rare occurrence. 3.6.2. Non Technical and Subjective Disagreements ------------------------------------------------- However, if the issue is non-technical and subjective, then a vote of the developers may be taken (USENET voting software should be available all over the place, right?), and a super-majority of 75% is needed to carry the amendment through. Failing the super-majority, the issue should be shelved. It may be re-submitted as a a fresh proposal after a suitable cooling off period (which should be no less than a month, typically three months being desirable, unless there are significant new developments). (Demote bug, if the BTS is being used) If the issue raised is especially contentious, or is deemed to be suitable for review by the full set of developers, then four or more developers can call for a hold on the proposal, and move to send the proposal to the larger developer body as a General Resolution. _Note:_ The constitution may have additional requirements for submitting a General Resolution, for example, a minimum number of seconders, etc. ------------------------------------------------------------------------------- A mechanism for updating Debian Policy documents Manoj Srivastava $Revision: 1.3 $