From: Manoj Srivastava Date: Thu, 16 Jun 2005 05:10:05 +0000 (+0000) Subject: Removing proposal.sgml X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=b137701a75b16db99b7f9902b932e244c1e587e2;p=debian%2Fdebian-policy.git Removing proposal.sgml Author: jdg Date: 2001/02/15 11:03:16 Removing proposal.sgml git-archimport-id: srivasta@debian.org--etch/debian-policy--devel--3.0--patch-81 --- diff --git a/proposal.sgml b/proposal.sgml deleted file mode 100644 index a2793c0..0000000 --- a/proposal.sgml +++ /dev/null @@ -1,388 +0,0 @@ - - - - - PROPOSAL: A mechanism for updating Debian Policy documents - - Manoj Srivastava - srivasta@debian.org - - $Revision: 1.9 $ - - Copyright © 1998 by Manoj Srivastava. - -

- 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.

-

- On Debian GNU/Linux systems, the complete text of the GNU - General Public License can be found in - `/usr/share/common-licenses/GPL'.

- - - - 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

- - 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. -

- - - 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. - - -

Michael Alan Dorman mdorman@debian.org

- - -

Richard Braakman dark@xs4all.nl

- - -

Philip Hands phil@hands.com

- - -

- - - - Archives and Personnel - - 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. -

- - - 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. -

- - - - Procedures and Processes - - 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 - -

- Encourage people to test the waters on the policy - mailing list, and this could help create an proposal - with a better chance of success

- - -

- 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. -

- - 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) -

- - - - 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.

- - 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. -

- - - - 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. -

- - 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.

- - - 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. -

- - - - 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] ...". 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. -

-

- developers may second the issue by emailing "seconded" - to the BTS. Only registered Debian developers may - second proposals. -

- - Amendment - -

- 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. -

-

- 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. - - Accepted - -

- if the amendment is accepted, the bug is marked - forwarded and retitled "[ACCEPTED DD/MM/YYY]...". -

- - Rejected - -

- if the amendment is closed, it is retitled as - "[REJECTED DD/MM/YYY] ..." and closed -

- - Incorporated - -

- When the proposal is actually integrated into Policy - and uploaded and moved into the archive, the bug is - closed. -

- - -

-

- 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.

- - - -