<name>Manoj Srivastava</name>
<email>srivasta@debian.org</email>
</author>
- <version>$Revision: 1.3 $</version>
+ <version>$Revision: 1.9 $</version>
<copyright>
- <copyrightsummary>
- This document is copyright 1998 Manoj Srivastava. Anyone is
- given permission to distribute this under the Freee software
- foundations General Public Licence, Version 2, or any later
- version, at your convenience.
+ <copyrightsummary>Copyright © 1998 by Manoj Srivastava.
</copyrightsummary>
+ <p>
+ You are given permission to redistribute this document
+ and/or modify it under the terms of the GNU General Public
+ License as published by the Free Software Foundation; either
+ version 2, or (at your option) any later version.</p>
+ <p>
+ On Debian GNU/Linux systems, the complete text of the GNU
+ General Public License can be found in
+ `<var>/usr/share/common-licenses/GPL</var>'. </p>
</copyright>
</titlepag>
<chapt>
- <heading>Introduction, and adminstrivia</heading>
+ <heading>Introduction, and Administrivia</heading>
<p>
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,
+ this team does not act as author or editor of Policy itself,
that is the task of the Debian Policy mailing list.
</p>
+ <p>
+ 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.
+ </p>
+ <p>
+ 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.
+ </p>
+ <p>
+ 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.
+ </p>
+ <p>
+ <em>In the following, the term developer refers to registered
+ Debian developers.</em>
+ </p>
<p>A copy of this document should also be found at <url
- id="http://master.debian.org/%7Esrivasta/proposal.html"></p>
+ id="http://master.debian.org/%7Esrivasta/policy/"></p>
<sect>
<heading>Deadline for tabling the discussion</heading>
<p>
</p>
</sect>
<sect>
- <heading>People Seconding the proposal</heading>
+ <heading>People Seconding the Proposal</heading>
<p>
- 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.<enumlist>
+ 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.
+ <enumlist>
<item>
<p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
</item>
<item>
<p>Richard Braakman <email>dark@xs4all.nl</email></p>
</item>
+ <item>
+ <p>Philip Hands <email>phil@hands.com</email></p>
+ </item>
</enumlist>
</p>
</sect>
</chapt>
<chapt>
- <heading>Archives and personnel</heading>
+ <heading>Archives and Personnel</heading>
<sect>
<heading>The policy maintainers team</heading>
<p>
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 excersice editorial control, Policy is
+ 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
</p>
<p>
The repository should contain all the packages under the
- control of the team, and also should have anrea where the
- weekly status document is kep; once the document is under
+ 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
- <tt>debian-poilcy</tt> and <tt>debian-devel</tt> mailing
+ <tt>debian-policy</tt> and <tt>debian-devel</tt> mailing
lists. This document could also be kept under CVS then.</p>
+ <p>
+ If possible, a separate mailing list (<tt>debian-policy-admin</tt>)
+ maybe created which gets copies of all the CVS commit
+ notices.
+ </p>
</sect>
</chapt>
<chapt>
- <heading>Procedures and processes</heading>
+ <heading>Procedures and Processes</heading>
<sect>
<heading>Proposing amendments to the Policy</heading>
<p>
policy amendment.
</p>
<p>
- The rationale behind the requirement for senconders is that
+ The rationale behind the requirement for seconders is that
it would<enumlist>
<item>
<p>
</item>
<item>
<p>
- Prevent frivoulous or ill concieved proposals from
+ 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?)</p>
</item>
</enumlist>
</p>
+ <p>
+ 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.
+ </p>
+ <p>
+ 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.
+ </p>
+ <p>
+ This document is not supposed to supplant the processes
+ outlined in the constitution, nor is it an end run around
+ them.
+ </p>
<sect1>
- <heading>Notifications and status reports</heading>
+ <heading>Notifications and Status Reports</heading>
<p>
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.</p>
- <p>
- 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.</p>
+ 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.</p>
<p>
Amendments to policy that have been accepted by the policy
- group shall also be part of the notification.</p>
+ group shall also be part of the notification. (recently
+ resolved bugs)
+ </p>
</sect1>
</sect>
<sect>
- <heading>Deadlines for tabling discussions</heading>
+ <heading>Deadlines for Tabling Discussions</heading>
<p>
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
+ 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
</p>
<p>
If a consensus is reached by the policy group, then the
- maintianers shall enter the amendment into the Policy
+ maintainers shall enter the amendment into the Policy
document, announce the inclusion in the periodic report, and
release a new version.</p>
<sect1>
- <heading>Extensions to deadlines?</heading>
+ <heading>Extensions to Deadlines?</heading>
<p>
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
- extention could be granted. Care should be taken in
+ extension could be granted. Care should be taken in
exercising this option, since abusing this would merely
- postpone closures. </p>
+ 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.
+ </p>
</sect1>
</sect>
<sect>
<p>
Formerly, arriving at a consensus was the only way to amend
Policy. That worked well when the Project was small,
- however, we have aparently grown out of that phase, and even
+ 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
discussion period is near, then one is faced with a dilemma.
</p>
<sect1>
- <heading>Impasse on technical issues</heading>
+ <heading>Impasse on Technical Issues</heading>
<p>
On technical issues, popularity is a bad way of arriving
at conclusions. Hopefully, the policy group would arrive
may be consulted. This should be a rare occurrence. </p>
</sect1>
<sect1>
- <heading>Non technical and subjective disagreements</heading>
+ <heading>Non Technical and Subjective Disagreements</heading>
<p>
However, if the issue is non-technical and subjective,
then a vote of the developers may be taken (USENET voting
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)</p>
+ <p>
+ 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. <strong>Note:</strong> The constitution may
+ have additional requirements for submitting a General
+ Resolution, for example, a minimum number of seconders,
+ etc.
+ </p>
</sect1>
</sect>
<sect>
- <heading>Using the bug tracking system</heading>
+ <heading>Using the Bug Tracking System</heading>
<p>
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 intiate discussions in the policy group
- by filing wish-list bugs (note: this should be open to
- anyone at all)</p>
- <p>
- 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 furhter notice. </p>
+ 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.</p>
+ <p>
+ <taglist>
+ <tag>Issue raised</tag>
+ <item>
+ <p>
+ wishlist bug opened in BTS, with a subject of
+ "[PROPOSED] ...". This is the pre discussion period,
+ when the idea is kicked around, and polished. There is
+ no preset time limit, but at some point, if it is
+ stalled, the bug should be closed. Only registered
+ Debian developers may formally create proposals.
+ </p>
+ <p>
+ developers may second the issue by emailing "seconded"
+ to the BTS. Only registered Debian developers may
+ second proposals.
+ </p>
+ </item>
+ <tag>Amendment</tag>
+ <item>
+ <p>
+ when a proposed issue becomes a formal amendment (when
+ it has acquired the required number of seconds), 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.
+ </p>
+ <p>
+ This sets up the table for a discussion period,
+ normally 10 days to a month. At the end of the
+ discussion period, a proposal is either accepted, or
+ rejected.
+ </item>
+ <tag>Accepted</tag>
+ <item>
+ <p>
+ if the amendment is accepted, the bug is marked
+ forwarded and retitled "[ACCEPTED DD/MM/YYY]...".
+ </p>
+ </item>
+ <tag>Rejected</tag>
+ <item>
+ <p>
+ if the amendment is closed, it is retitled as
+ "[REJECTED DD/MM/YYY] ..." and closed
+ </p>
+ </item>
+ <tag>Incorporated</tag>
+ <item>
+ <p>
+ When the proposal is actually integrated into Policy
+ and uploaded and moved into the archive, the bug is
+ closed.
+ </p>
+ </item>
+ </taglist>
+ </p>
<p>
I think that the Policy is critical enough for the project
that any real flaws in the policy be automatically be deemed
projects / debian / debian-policy.git / blobdiff