In the IRC discussion I said I would write up a proposal, so here it is. I've used the word `standards' everywhere instead of `policy'; I think this would be a good renaming, because it would emphasise that we're trying to do technical things rather than politics ...
DRAFT Standards Process ----------------- DRAFT 0. Introduction This document describes how standards are set in Debian. A standard is a document or program which sets an interface or specification that many other packages need to adhere to. This includes the core standards which apply to all packages, as well as subsystem-specific standards. This document also says how we handle disputes relating to standards, and permits the use of the debian-standards list to discuss any disputed bug report. 1. Scope of standards documents Standards do not, of course, describe all of the requirements for having a system that works well. There are many kinds of bugs or misfeatures which are not standards violations; the fact that something is not prohibited by a standard does not mean that it is a good idea, or that doing it is not a bug. However, if a standards document categorically states a requirement, then if a package violates that requirement either the package or the standard must be wrong. 2. Editors Standards are contained within Debian packages. Each standards document, or part of a document, or area of responsibility, belongs to one or more standards editors. Only the relevant standards editors should make changes to the standards. Usually, the standards editors will be (some of) the maintainers of the packages containing the standards. The editors of a standard should be identified in the documents which describe the standard. The editors for a standard have the primary responsibility for maintaining and updating that standard. However, they should seek and obtain consensus for their decisions, as described below. The core standards documents, contained in the debian-standards package, are maintained in CVS by a team. Each document, or part of a document, has one or more editors within that maintainer team. Only the editor(s) responsible for a particular area should check in changes to that section, and then only when rough consensus has been achieved (see below). Other standards documents may be written and distributed as part of other packages; the authors of these documents and the maintainers of these packages decide who is the standards editor. Often, for a non-core standard, there is only one package maintainer who is also the standards editor. Initially, the author of a standards document or section will usually become its editor. If they wish to retire from that position they should usually pass on the responsibility. In cases of dispute about who should edit a standard the Project Leader will decide. The Leader should appoint additional editors for a particular standard, or remove or replace editors, whenever this would benefit the project as a whole. 3. Communication and consensus Standards created without adequate discussion and consensus are both likely to be less than ideal, and not to be widely supported. Therefore, standards editors should consult the debian-standards mailing list before promulgating new or changed standards. Standards should only be promulgated after at least rough consensus has been achieved on debian-standards. The relevant standards editor should announce their intention to make the change and then wait at least a week for objections to be heard. If during the discussion of a proposed change significant disagreement is expressed, the relevant standards editor should state when they think rough consensus has been achieved, and wait at least a week before promulgating the change. Of course, standards editors are encouraged to accept helpful submissions and suggestions from members of the debian-standards group, or from any other developer, if there is rough consensus in the standards group in favour of the suggestion. When a new standard is promulgated, or is to be promulgated, the debian-standards group should be informed. If the change is particularly significant, all the developers should be informed via the debian-devel-announce list. 4. Standards group chairs The debian-standards group has one or more chairs, appointed by the Project Leader. The chairs should help to promote productive debate. If a chair states that they feel that rough consensus has not been achieved, then the standards change should not be promulgated until a chair states that rough consensus has now been achieved; likewise if after a change has been promulgated a chair states that they feel that rough consensus was not achieved and that the change should be reversed until it has been, then the change should indeed be reversed as soon as possible. When there is doubt about whether rough consensus has been achieved the standards editor should ask the chairs to decide. For particularly significant changes, or ones which might be expected to be controversial, standards editors should allow longer for objections take a more cautious approach when estimating consensus, for example by always seeking the advice of the chairs. Rough consensus means that nearly everyone agrees. Rough consensus has not been achieved if the relevant standards editor disagrees. 5. Dispute resolution There will occasionally be a need for clarification, and disagreements will occasionally arise between standards editors, members of the standards group, or package maintainers or other developers who disagree with the standards or their interpretation. Disagreements about standards should initially be raised and discussed on the debian-standards list. If and when rough consensus is achieved it should be implemented by the appropriate standards editors and package maintainers. While the disagreement is outstanding and being discussed on debian-standards, any relevant bug reports should remain open, and should be assigned for the time being to the package containing the relevant standards. If rough consensus cannot be achieved the matter should be referred to the Technical Committee (if the question is technical), or the Project Leader (if the question concerns Debian's goals and priorities), as specified in the Debian Constitution. If both technical and nontechnical matters are involved the Technical Committee and Project Leader should discuss it together and jointly agree a decision (and/or the process for making the decision). 6. Disputed bug reports If bug submitter(s) who are also developer(s) and package maintainer(s) disagree about whether a particular bug report actually describes a bug, or what should be done about it, any of them may choose to discuss the matter on debian-standards even if the issue is not directly related to Debian's standards. In this case all parties should read and participate in the relevant discussion there. The discussion should examine the issues from a technical point of view, and in a nonconfrontational way. Hopefully this will allow the submitter and maintainer to come to agreement on the correct way forward. While discussion about a disputed bug report continues the bug report should remain open so that it is not lost. If no agreement can be reached then disputed bugs should be referred to the Technical Committee or the Project Leader, as appropriate. Ian.