From 8412588506d3933bc8b7d85f17a81b365949a855 Mon Sep 17 00:00:00 2001 From: Manoj Srivastava Date: Thu, 16 Jun 2005 05:02:21 +0000 Subject: [PATCH 1/1] Initial revision Author: srivasta Date: 1998/08/07 19:22:40 Initial revision git-archimport-id: srivasta@debian.org--etch/debian-policy--devel--3.0--base-0 --- proposal.sgml | 247 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 247 insertions(+) create mode 100644 proposal.sgml diff --git a/proposal.sgml b/proposal.sgml new file mode 100644 index 0000000..7c352db --- /dev/null +++ b/proposal.sgml @@ -0,0 +1,247 @@ + + + + + PROPOSAL: A mechanism for updating Debian Policy documents + + Manoj Srivastava + srivasta@debian.org + + $Id: proposal.sgml,v 1.1 1998/08/07 19:22:40 srivasta Exp $ + + + 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. + + + + + Introduction, and adminstrivia +

+ 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, + that is the task of the Debian Policy mailing list. +

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

+ + +

+ + + + 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, not does it excersice 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 anrea where the + weekly status document is kep; 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-poilcy and debian-devel mailing + lists. This document could also be kept under CVS then.

+ + + + 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 senconders 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 frivoulous or ill concieved proposals from + wasting peoples time (If the proposal does not even + convince two developers, surely this is not ready for + inclusion in Policy?)

+ + +

+ + 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. The list of topics + should be posted on the web as well.

+

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

+

+ Amendments to policy that have been accepted by the policy + group shall also be part of the notification.

+ + + + 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 + maintianers 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 + extention could be granted. Care should be taken in + exercising this option, since abusing this would merely + postpone closures.

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

+ + + + 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 intiate discussions in the policy group + by filing wish-list bugs (note: this should be open to + anyone at all)

+

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

+

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

+ + + + -- 2.39.5