On Sat, 28 Oct 2006 17:23:33 +1000, Anthony Towns <aj@azure.humbug.org.au> said:
> On Fri, Oct 27, 2006 at 10:01:26PM -0500, Manoj Srivastava wrote: >> > The technical committee charter and the policy process both adopt >> > the principle that the people making the change [..] only act in >> > an editorial capacity -- reviewing changes and committing them >> > appropriately, but not do actual design work in their formal >> > hats. >> But they also take the lead in discussions, and can and do decide >> if there are opposing opinions as to which opinion carries the >> day. Part of taking lead in the discussion is having the ability to >> say "Stop, we have heard all arguments on this already, based on >> the current positions of people on the list, this option is what we >> shall decide to do.". > Agreed absolutely. > The only point I'm emphasising is that you don't just have to hear > the arguments, you have to ensure they're made somewhere that others > can hear them too. I agree. And the place where people can here the arguments is the debian-policy mailing list; even under the old process, porposals were refined on the list, and areguments were put forth for and against alternate strategies that helped shape the final proposal; and the final proposal was what was put to the BTS, and seconded, and only the final polishing discussion ever made it to the BTS. This is similar in nature to general resolutions: the arguments made on the debian-vote list are not what makes it to the vote.debian.org mailing list. > So does something like the following sound plausible? > 1. Trivial policy updates that don't change the substance of > policy (markup changes, fixing typos) will be made by the > policy maintainers as they see fit. > 2. Other changes will have a patch submitted against a bug > assigned to the debian-policy package in the BTS, and forwarded > on to any developers specifically affected by the proposed > changes. > 3. Once three developers or one of the policy maintainers (other > than the proposer) have indicated they support the proposed > change, the bug can be tagged "confirmed", and will then be > reviewed by the policy maintainers as a group. > 4. If the policy maintainers are satisfied with the proposed > change, the patch will be committed to the policy revision > control system and the bug will be tagged "pending". > 5. If at any point the policy maintainers are not satisfied with > the proposed change or the reasoning behind it, they may make > suggestions tag the bug "wontfix", and/or close the bug. > 6. Policy should be designed to meet the concerns of all > developers, and all suggestions should be taken into account as > far as possible. > That has a single process that applies to everybody, seems > reasonably quick for changes the maintainers propose, works even if > there's only one active policy maintainer, and requires at least one > person other than the proposer to review every change. > I assume you can already think up a bunch of improvements to the > above skeleton, but does the general shape match what you're > thinking? That is a good starting point. But if we are going to revamp the policy modification process, let us examine the goals, and the logical states of the state machine of a policy change use case. Goals: 1) The change should be technically correct, and consistent with the rest of the policy document. This means no legislating the value of Pi 2) The change should not be too disruptive; if very many packages become instantly buggy, then instead there should be a transition plan. There could be very rare exceptions to this rule, if the current state is really untenable. In which case, though, the TC should probably be involved. 3) The change has to be reviewed in depth. The discussion should be held in the open, where any one may contribute; a publicly accessible, open mailing list which is archived should be fine. 4) Any domain experts should be consulted, since not every policy mailing list subscriber is an expert on everything, including policy maintainers. 5) The goal is rough consensus on the change, which should not be hard if the matter is technical. Technical issues where there is no agreement should be referred to the TC; non-technical issues should be referred to the whole developer body, and perhaps general resolutions lie down that path. 6) Package maintainers whose packages may be impacted should have access to policy change proposals, even if they do not subscribe to policy. This last bit is where I am slightly concerned -- we have never done a good job on early notification. However, with 15,000 packages and climbing, putting the task of determining which packages are affected can be very burdensome on the active policy maintainers (heh). I would suggest instead a Weekly Policy News, or the Policy Monthly Gazette, or something, that people may subscribe to for a low volume announcement list. Indeed, it can be an announce only list, and a synopsis of the proposal and a rationale can be posted to it when we reach the stage where the proposal is nearing the final form. Given these goals, what are the steps or stages to reach there? Here is my take at the states of a state machine: State A: There is a gap in current policy. For example, if there are potentially several technically viable options that can be taken, and it would help integration if all packages affected can rely on one solution, it would help integration. Any user or developer should be able to point to such a deficiency, and this can be an injection point of a policy change into the system. There is a decision point here: some issues raised might not be in the purvue of a policy change (I do not like the name iceweasel, policy should prevent ice and a rodent in the name of any package). This state is optional, some proposals can go right to stage B State B: Initial suggestions for a policy to address some such need. This may not have formal policy language yet, or a diff against current policy. This is when discussion happens, alternate proposals are floated, and the nitty-gritty details of policy creation are done. Policy delegates, if any, should guide, but not control, this discussion; they can help nudge the process along if the discussion has reached an impasse, suggesting one alternative or the other. The guidance could stop a circular discussion in which no new arguments are forthcoming and decide in favour of the majority opinion, for instance, to prevent a vocal minority from derailing the process. Much care has to be exercised here, and we should probably come up with a means for appealing any thing -- to another policy delegate, perhaps? If there is an arcane technical area involved, and there are domain experts for that area, we may optionally go to: Stage C: Solicit domain expert input. In most cases, it is easy to determine who the domain experts are; usually the maintainer of related packages either are domain experts or can point to domain experts. This state is optional, and has two exit points: either we get the domain expert testimony, and perhaps a dialogue ensues, or we time out (I mean, domain experts need not pay attention to us, etc) At this point, there should either be the case where we have a fair idea of what change is required, or have come to the conclusion we can't agree. There should be support from three developers at this point, before we proceed to the next phase (or a developer and a delegate -- dunno if we should really special case the delegate here) State D: Formal change language is created for the policy change, any transition plans are sketched in, a rationale is attached as a footnote, if appropriate, for future reference. At this point, the policy change goes to the Policy Gazette, so other people affected may join the discussion, if they please. State E: The proposal is sponsored by three developers. States D and E may happen in any order, but both are required before we move to the next state. Final discussions happen here. There should be ample time for people who are affected by this change to have read the Gazette and come in to voice their inputs; final refinements to the language happen now. This is again a decision point; either we have a rough consensus, or we need to send the initial problem, and the fact we can't agree, off to the TC or the developer body at large. State F: the change is accepted, and is waiting for the next policy update (which may not happen for a while, for example, if policy is frozen fro a release). State G: Not policy decision Stage H: Time out, no formal policy language ever proposed State I: referred to TC State J: referred to debian-devel State K: Rejected by delegates Now, coming back to procedures. Should all states in the above state machine be tracked in the BTS? From past experience, even though the old policy process had state tracking via the BTS, most people never did track state B -> state D changes in the BTS. Things like state C tracking in the BTS seem like a lot of red tape. User tags would be great for tracking flow of a change through the state machine, though. We can leave severities well enough alone: the severity can reflect a consensus of how critical a policy change is, in the eyes of the proposer and debian-policy regulars, and unrelated to the progress the proposal has made, which is tracked by usertags and user categories. 1. Trivial policy updates that don't change the substance of policy (markup changes, fixing typos) will be made by the policy maintainers as they see fit. 2. Flaws/Defects in policy should have a normal or important bug filed against policy in the BTS. The usertag is the one reserved for "State A", unless 4. applies. 3. Gaps in policy should be filed with a wishlist priority. Usertag is still the one reserved for "State A", unless 4. applies. 4. If a solution for the gap or flaw is also proposed initially, the usertag is the one related to "State B", skip to 6. 5. Discussion on the gap/defect happens, and a tentative solution is proposed. the usertag is the one related to "State B". 6. Input is solicited from domain experts, as needed. Time is allowed for such experts to provide input. 7. Once three developers or one of the policy maintainers (other than the proposer) have indicated they support the proposed change, usertag corresponding to stage E is added. 8. Formal policy language is specified for the bug. usertag corresponding to stage D is added. At this point, this Bug gets sent to the policy-announce mailing list. Final reviews and discussions start. 9. Policy should be designed to meet the concerns of all developers, and all suggestions should be taken into account as far as possible. If the policy maintainers are satisfied with the proposed change, the patch will be committed to the policy revision control system. The usertag corresponding to "State F" is added. 10. If policy maintainers think that the proposed change does not meet the concerns of all maintainers, or no formal language or solution can be agreed upon, the may forward the issue to the TC or the developer body; usertags for States H, I, or J may be added. 11. If at any point the policy maintainers are not satisfied with the proposed change or the reasoning behind it, they may make suggestions tag the bug "wontfix", and/or close the bug. The usertag for state K is added. manoj -- Go to a movie tonight. Darkness becomes you. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]