>>"Brock" == Brock Rozen <[EMAIL PROTECTED]> writes:
Brock> Well, I definitely think we should start with something
Brock> lightweight -- but the whole process of accepting
Brock> proposals/amendments should eventually become formalized, with
Brock> specific rules on how it's done -- IMHO.
What do you find lacking in the current methodology? I
specifically direct your attention to section 3.3, Deadlock
resolution, and 3.3.2. Non Technical and Subjective Disagreements.
Since there has been a great deal of confusion about this, I
shall repost this to the list, and include this as a part of the
policy package
manoj
PROPOSAL: A mechanism for updating Debian Policy documents
----------------------------------------------------------
Manoj Srivastava<[EMAIL PROTECTED]>
$Revision: 1.7 $
-------------------------------------------------------------------------------
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 does not call
for the modification 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 <[EMAIL PROTECTED]>
2. Richard Braakman <[EMAIL PROTECTED]>
3. Philip Hands <[EMAIL PROTECTED]>
-------------------------------------------------------------------------------
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.
If possible, a separate mailing list (`debian-policy-admin') maybe
created which gets copies of all the CVS commit notices.
-------------------------------------------------------------------------------
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.
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)
If the issue raised is especially contentious, 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.
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 simplifies how me
manage and track open amendments and issues. I think both re-titling
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 proposed 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<[EMAIL PROTECTED]> $Revision: 1.7 $
--
Money doesn't talk, it swears. Bob Dylan
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
