[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The policy process and user categories



Manoj Srivastava <srivasta@debian.org> writes:

>         This is going to be a long email.  I am contemplating the
>  holiday festivities, and am getting into the zen mode for making
>  traditional egg nog.  Where I live, traditional egg nog means
>  contemplating very old Kentucky straight bourbon whiskey, and single
>  cask Jamaican white rum,  amongst other things.  Making good egg nog
>  makes one inclined t wax long and lyrical.

*grin*

>         Here is the policy change process as a state machine:
> SATE DIAGRAM
>     * State A: Issue raised.  Detect need, like gaps/flaws in
>       current policy, or a new rule should be added. Any user or
>       developer may start this step. There is a decision point here,
>       not all issues are in scope of policy.                 [TAG: issue]
>     * State B:Discussion Discuss remedy. Alternate proposals. Discussion
>       guided by delegates. There should be a clear time limit to this
>       stage.                                            [TAG: discussion]
>     * State C:Solicit advice [Optional] Solicit domain expert input
>                                                            [TAG: opinion]
>     * State D:Proposal.  A final proposal has emerged from the
>       discussion, and there is a rough consensus on how to proceed to
>       resolve the issue.                                  [TAG: proposal] 
>     * State E:Wording proposed Close to a working solution. Create
>       policy language, rationale, test, and publish.      [TAG: wording]
>     * State F:Seconded The proposal is signed off on by N developers,
>       N=3? (stages D and E may be reversed) Final discussions start;
>       input from affected developers.                     [TAG: seconded]

One concern that I have here is that getting seconds is rather hard.  For
example, the change to allow comments in the Version field of binary
packages specifying the source version was requested by a dpkg maintainer
and reflected current reality, but never got any seconds.  I just
committed it anyway.

That doesn't rule out use of the tag, of course, just that if there's an
expert opinion or if the change seems to the Policy delegates to be
obviously correct, I think it should be possible to skip the seconded
stage in the process.

Of course, it will improve Policy in the long run to have a lot of active
participants checking wording and raising concerns, so ideally we wouldn't
have to do that often.

>     * State G:Accepted Change accepted, will be in next upload.
>                                                           [TAG: accepted]
>     * State H:Reject Rejected proposals.                  [TAG: rejected]
>       These can be one of:
>            H1:dubious   Not a policy matter              [TAG: dubious]

I'd been using "dubious" to mean that I *think* the proposed change isn't
a Policy matter or is premature, but I'd prefer to get someone else to
double-check me on it.  Maybe we can keep the tag for that purpose and use
a different tag for this rejection (invalid, perhaps?).

Then, if one Policy delegate tags something dubious and another Policy
delegate concurs, they can then tag it with one of the other rejection
tags and close the bug.

>            H2:Ctte      Referred to TC                   [TAG: ctte]
>            H3:Devel     Referred to developer body       [TAG: devel]
>            H4:Delegate  Rejected by delegates            [TAG: delegate]
>                         (sent by default to TC)
>            H4:Timeout   Timed out, no policy created.    [TAG: obsolete]

In general, my assumption is that we'll both tag rejected proposals *and*
close the bug so that the Policy bug list doesn't get out of control with
wontfix bugs.

>         I have since used that framework, and I am proposing expanding
>  the user tags and using the user debian-policy@lists.debian.org as the
>  default user.  I have expanded on the scheme used by Russ, to better
>  match the proposals for the process (adding in seconds, etc).
>  Experimenting with these user categories, new proposals pop to the top,
>  helping me quickly see new proposals, and letting me categorize them.
>
>         Please look at
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=srivasta@debian.org&ordering=policy
>  for a preview.

This looks great to me.  I'd be happy to go ahead and set these tags and
ordering for debian-policy@lists.debian.org and start using it as the
default bug triage system.  I'll then stop maintaining my own separate set
of tags and use this directly.

>         These user categories also help in making the process more
>  efficient, and predictable; it also help direct effort (for example, my
>  primary effort at the moment is to look at all the proposals
>  categorized as wording; with an eye to bringing them to
>  resolution. This is where seconds would help.  The people seconding
>  shoul perhaps include any reasons they have for seconding, if they
>  think it would help others see the validity of the wording proposed.

Agreed.

I'm going to take a pass through all of the proposals tagged wording now
and update the proposed wording if necessary.

>         In any case, either these proposals should be accepted, or
>  rejected, or sent back to discussion: perhaps we should discuss what a
>  time limit should be for each stage the proposal spends its time in?

I'd say that one month from wording to seconded or accepted is reasonable,
and if it takes more than a month, the state should revert to discussion.
That's going to indicate a wording proposal that no one really feels quite
good enough about to approve, I think.

>         I suggest that all the usertags for the policy, apart from the
>  second usertag, only be applied by the policy delegates, and that any
>  DD be allowed to add a usertag seconded to any report that already has
>  the wording usertag.

Agreed.

>         Additional usertags are:
>  * dubious, ctte, devel, delegate,timeout These are mostly used to add
>    reasons for rejection; or why the delegates are tending towards
>    rejection of a particular proposal.
>  * dpkg, security

I'd been using dpkg to tag any proposal that's primarily about how dpkg
works rather than about the broader aspects of Policy.  My vague intent
with that tag is to treat the opinions of the dpkg maintainers specially
when it comes to bugs tagged dpkg.  In other words, if the dpkg
maintainers say that a given change is correct, I wouldn't worry as much
about the regular seconding process.

I'm not sure if that's a good idea or not, but as long as we have a lot of
technical information about how dpkg and maintainer scripts function in
Policy, it seems like we need to keep it up to date with how dpkg
functions in practice for it to be useful.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: