Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
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 <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: