Revised policy process - proposal
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.
Reply to: