From 8412588506d3933bc8b7d85f17a81b365949a855 Mon Sep 17 00:00:00 2001 From: Manoj Srivastava <srivasta@debian.org> 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 @@ +<!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>$Id: proposal.sgml,v 1.1 1998/08/07 19:22:40 srivasta Exp $</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> + </titlepag> + <chapt> + <heading>Introduction, and adminstrivia</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, + that is the task of the Debian Policy mailing list. + </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 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> + </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, 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. + </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 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 + <tt>debian-poilcy</tt> and <tt>debian-devel</tt> mailing + lists. This document could also be kept under CVS then.</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 senconders 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 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?)</p> + </item> + </enumlist> + </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. 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> + <p> + Amendments to policy that have been accepted by the policy + group shall also be part of the notification.</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 + maintianers 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 + extention could be granted. Care should be taken in + exercising this option, since abusing this would merely + postpone closures. </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 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.</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> + </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 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> + <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> -- 2.39.5