Revised proposal for updating Debian Policy documents
Hi,
This is the middle of the discussion period for this
proposal. I have tried to incorporate the results of discussions on
the list; please do not hesitate to correct any errors or
omissions. (Note that aph's suggestions for using the BTS have been
incorporated).
The changed protions of this document are marked with
changebars (thats what the '+' in the first column means).
If you look at the werb version in a fairly recent browser,
the changed texct would appear to be green (or whatever your style
sheet does to *.CHANGED elements).
manoj
______________________________________________________________________
PROPOSAL: A mechanism for updating Debian Policy documents
----------------------------------------------------------
Manoj Srivastava<srivasta@debian.org>
+ $Revision: 1.6 $
-------------------------------------------------------------------------------
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 itself, that is the task of the Debian Policy
mailing list.
+ It should also be pointed out that this proposal itself doess not call
+ for the modificxation of the Policy documents themselves. I would
+ rather not rush into anything as serious as modification of the formal
+ policy documents themselves, and I suspect that we would learn and
+ refine this process in practice. I would rather that the formal
+ modifications be deferred until after the kinks of this process have
+ been worked out.
+
+ Another thing that bears mentioning is that this proposal is only for
+ the every day routine functioning of the policy group. Traditionally,
+ the policy group, under the aegis of the Policy editor, worked on the
+ basis of a consensus derived in the group. This proposal merely
+ removes the need of a dedicated policy editor, and passes the debian
+ packages that contain the policy into the hands of a few people who no
+ longer exercise editorial control, and, paying homage to our growth,
+ relaxes the requirement for a consensus.
+
+ This is not supposed to change the way the group works, except in
+ minor detail. There are some policy changes 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 objection) should the intervention of
+ Constitutional bodies come into play. In any other situation, the
+ Policy group should be able to conduct business unfettered. This is
+ the only way we can continue to improve Debian.
+
+ *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/%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, Phil Hands, 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>
+ 3. Philip Hands <phil@hands.com>
-------------------------------------------------------------------------------
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, 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 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?)
+ 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 contentous, and needs something like votes on
+ amendments and withdrawl of proposal, then this is not the correct
+ forum for this, and the procedures outlied in the constitution should
+ be followed.
+
+ This document is not suppoed 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.
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 the issue raised is especially contentous, 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.
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) This simplies how we
+ manage and track open amendments and issues. I think both retitling
+ and the severity of the bugs can and should be used.
+
+ Issue raised
+ wishlist bug opened in BTS, with a subject of "[PROPOSED] ..."
+
+ Seconds
+ developers may second the issue by emailing "seconded" to the
+ BTS. (Issue: what if the so called seconder is not a registered
+ Debian developer?)
+
+ Amendment
+ when a propsed issue becomes a formal amendment, the bug severity
+ is raised to "normal" and the bug is retitled to "[AMENDMENT
+ DD/MM/YYY] ...". Actually it might be better to close the
+ proposal and reopen so the bug date reflects when the clock
+ starts ticking on the bug; in which case the bug could simply be
+ retitled "[AMENDMENT] ...".
+
+ Accepted
+ if the amendment is accepted, the bug is marked forwarded, until
+ it is actually integrated into Policy and uploaded and moved into
+ the archive, at which time the bug is retitled "[ACCEPTED]..."
+ and closed.
+
+ Rejected
+ if the amendment is closed, it is retitled as "[REJECTED] ..."
+ and marked as closed
+
+ Deadlocked
+ if the amendment is deadlocked, it is marked as "[DEADLOCKED]
+ ...",
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.6 $
--
Law of Selective Gravity: An object will fall so as to do the most
damage. Jenning's Corollary: The chance of the bread falling with
the buttered side down is directly proportional to the cost of the
carpet. Law of the Perversity of Nature: You cannot determine
beforehand which side of the bread to butter.
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
Reply to: