From e7e00209cd1bb2e0bb6507a8e8bed8253fa906c2 Mon Sep 17 00:00:00 2001
From: Manoj Srivastava
- It should also be pointed out that this proposal itself doess - not call for the modificxation of the Policy documents + 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 @@ -48,7 +48,7 @@ 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 + 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. @@ -149,6 +149,11 @@ 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. +
- If the process gets very contentous, and needs something - like votes on amendments and withdrawl of proposal, then + 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 - outlied in the constitution should be followed. + 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 suppoed to supplant the processes + This document is not supposed to supplant the processes outlined in the constitution, nor is it an end run around them.
@@ -242,7 +251,10 @@ 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. + 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. +- If the issue raised is especially contentous, 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. -
If a consensus is not reached, (or if someone submits a formal objection to the proposal) and the end of the @@ -294,6 +296,17 @@ 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. +
- when a propsed issue becomes a formal amendment, the
+ when a proposed issue becomes a formal amendment, 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
--
2.39.2