+++ /dev/null
-<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
-<debiandoc>
- <book>
- <titlepag>
- <title>PROPOSAL: A mechanism for updating Debian Policy documents</title>
- <author>
- <name>Manoj Srivastava</name>
- <email>srivasta@debian.org</email>
- </author>
- <version>$Revision: 1.9 $</version>
- <copyright>
- <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 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 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/policy/"></p>
- <sect>
- <heading>Deadline for tabling the discussion</heading>
- <p>
- 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.
- </p>
- </sect>
- <sect>
- <heading>People Seconding the Proposal</heading>
- <p>
- 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>
- <sect>
- <heading>The policy maintainers team</heading>
- <p>
- 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.
- </p>
- <p>
- 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.
- </p>
- </sect>
- <sect>
- <heading>The CVS Repository</heading>
- <p>
- There should be a repository set up on
- <tt>cvs.debian.org</tt> for this, with the people on the
- policy maintainer team having write access to it.
- </p>
- <p>
- 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
- <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>
- <sect>
- <heading>Proposing amendments to the Policy</heading>
- <p>
- 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.
- </p>
- <p>
- The rationale behind the requirement for seconders is that
- it would<enumlist>
- <item>
- <p>
- Encourage people to test the waters on the policy
- mailing list, and this could help create an proposal
- with a better chance of success</p>
- </item>
- <item>
- <p>
- 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>
- <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. 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. (recently
- resolved bugs)
- </p>
- </sect1>
- </sect>
- <sect>
- <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
- 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.
- </p>
- <p>
- 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.</p>
- <sect1>
- <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
- 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.
- </p>
- </sect1>
- </sect>
- <sect>
- <heading>Deadlock resolution</heading>
- <p>
- 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.</p>
- <p>
- 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.
- </p>
- <sect1>
- <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
- 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. </p>
- </sect1>
- <sect1>
- <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
- 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)</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>
- <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 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
- important bugs, unless they affect release management.</p>
- </sect>
- </chapt>
- </book>
-</debiandoc>
projects / debian / debian-policy.git / commitdiff