PROPOSAL: A mechanism for updating Debian Policy documents
Hi,
This is my formal proposal for the Debian policy
documents. Though this is being sent to beoth the -devel and the
-policy lists, discussions of this proposal really belong on the
policy lists, so please send comments to debian-policy@lists.debian.org
(You do not need to be subscribed).
manoj
______________________________________________________________________
----------------------------------------------------------------------
PROPOSAL: A mechanism for updating Debian Policy documents
----------------------------------------------------------
Manoj Srivastava<srivasta@debian.org>
$Revision: 1.5 $
-------------------------------------------------------------------------------
1. Introduction, and Administrivia
----------------------------------
This is a proposal for creating a process through which the Debian
Policy documents are to be maintained and updated, it sets forth the
processes, and also calls for the creation of a team responsible for
the task of updating policy, however, this team does not act as author
or editor of Policy it self, that is the task of the Debian Policy
mailing list.
A copy of this document should also be found at
http://master.debian.org/%7Esrivasta/policy/
1.1. Deadline for tabling the discussion
----------------------------------------
I decided to use the suggested "usual" period of two weeks for this
proposal. Therefore, this proposal needs to be acted upon before
August the 22nd, 1998.
1.2. People Seconding the Proposal
----------------------------------
Well, since Michael Alan Dorman and Richard Braakman have volunteered
to serve on the policy maintainer team, I think they have no objection
to being seconds.
1. Michael Alan Dorman <mdorman@debian.org>
2. Richard Braakman <dark@xs4all.nl>
-------------------------------------------------------------------------------
2. Archives and Personnel
-------------------------
2.1. The policy maintainers team
--------------------------------
I propose we select/install 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, not 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 lists, which is how
it was always done; so the group of policy maintainers have no real
power over policy. Since they would have access to the CVS repository
I guess it is desirable that the people so appointed be ``mature'',
however that is determined.
I think that since the policy maintainers have no special powers,
there is no need to restrict their participation in the discussion. We
do need to have at least 4-5 people on the job, preferably 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 archives of the list 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 should be a repository set up on `cvs.debian.org' for this, with
the people on the policy maintainer team having write access to it.
The repository should contain all the packages under the control of
the team, and also should have an area where the weekly status
document is kept; once the document is under CVS, it should be a
simple matter to script exporting the document out to a place where
the web server can serve it, as well as create the weekly posting to
`debian-policy' and `debian-devel' mailing lists. This document could
also be kept under CVS then.
-------------------------------------------------------------------------------
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?)
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. The list of topics should be posted on the web as well.
If the current topic list is kept in CVS, then a simple script could
handle both the tasks, and all the maintainers need do is keep the CVS
repository up do date. If the Bug tracking system is used, this may be
semi-automated too.
Amendments to policy that have been accepted by the policy group shall
also be part of the notification.
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.
3.3. 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.3.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.3.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)
3.4. Using the Bug Tracking System
----------------------------------
A fascinating sub proposal has been that we use the bug tracking
system to track policy amendments in progress. If this is used, we may
initiate discussions in the policy group by filing wish-list bugs
(note: this should be open to anyone at all)
Formal proposals should be treated as normal bugs, and after the
discussion period are either closed (when incorporated in policy, or
roundly rejected as undesirable), or are demoted to (forwarded?) wish
list bugs. I like them being demoted to forwarded status, since the
upstream authors (the policy mailing list) has already had a stab at
them, and they have been shelved until further notice.
I think that the Policy is critical enough for the project that any
real flaws in the policy be automatically be deemed important bugs,
unless they affect release management.
-------------------------------------------------------------------------------
PROPOSAL: A mechanism for updating Debian Policy documents
Manoj Srivastava<srivasta@debian.org> $Revision: 1.5 $
--
Mind precedes its objects. They are mind-governed and mind-made. To
speak or act with a defiled mind is to draw pain after oneself, like
a wheel behind the feet of the animal drawing it. 1
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: