[ previous ] [ Copyright Notice ] [ Contents ]

PROPOSAL: A mechanism for updating Debian Policy documents - Chapter 3
Procedures and Processes


3.1 Proposing amendments to the Policy

Unlike before, when the policy editor gathered in issues which, in his view, were candidates for inclusion in policy, I propose that issues are brought up in the policy group, and, if the initial discussion warrants it, any developer, with at least two(?) seconds can formally propose as a policy amendment.

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 light weight; 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 an end run around them.


3.1.1 Notifications and Status Reports

Periodically, possibly weekly, a summary of current policy topics can be posted to the Developers mailing list, as well as to the policy mailing list. Since the BTS is used for keeping track of policy amendments, the list of current amendments shall always be on the web.

Amendments to policy that have been accepted by the policy group shall also be part of the notification. (recently resolved bugs)


3.2 Deadlines for Tabling Discussions

It has been observed in the past that discussions on the mailing list 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.2.1 Extensions to Deadlines?

If a deadline is approaching, and the discussion s 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.