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

The policy process and user categories


        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.

        You have been warned.

        Oh, and please send responses to the debian-policy mailing list.

        The genesis of this current development is in the discussion (if
 I may call it that) that emerged around the un-delegation and
 re-delegation of the policy team, which means circa October '06.

        In the mail of:
 I spell out some of the bits missing from the old policy change
 process; for example, soliciting and paying special heed to domain
 expert advice, leading and abridging discussion on policy changes, etc.

 I talk about the goals of the policy change process, and the initial
 draft of what the new process would look like.

        Last DebConf, I gave a talk titled: "The Policy and RC bug
 goulash", which can be found at
 The talk deals with two things: the policy rewrite, and the changes to
 the policy process itself.  I have already broached the re-write in
 another thread, here is my proposal to move to the new policy process,
 and to further open up the policy change process.

        So, to recap, here are the goals for the policy change process:

  * The change should be technically correct, and consistent with the
    rest of the policy document. This means no legislating the value of
    $\Pi$. This also means that the proposed solution be known to work;
    iterative design processes do not belong in policy.
  * The change should not be too disruptive; if very many packages
    become instantly buggy, then instead there should be a transition
    plan.  Exceptions should be rare (only if the current state is
    really untenable), and probably blessed by the TC.
  * The change has to be reviewed in depth, in the open, where any one
    may contribute; a publicly accessible, archived, open mailing list.
  * Proposal should be addressed in a timely fashion.
  * Any domain experts should be consulted, since not every
    policy mailing list subscriber is an expert on everything,
    including policy maintainers.
  * 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.
  * Package maintainers whose packages may be impacted should have
    access to policy change proposals, even if they do not subscribe to
    policy mailing lists (policy gazette?).

        Here is the policy change process as a state machine:
    * 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]
    * 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]
           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]

        Hopefully, the timeout rejection of policy changes will not be
 exercised very often; if it is, perhaps the process should be

        Russ Allbery took the above proposal and ran with it, creating a
 user tag view of policy
 This allows users to see what the policy delegates think is the state
 of the process, and allows for a transparent mechanism for looking at
 the state of the policy change proposals.  It would also help people
 interested in joining the policy team to help the process along;
 propose policy wording for proposals at the end of discussion, help
 determine if the wording proposed meets policy goals, etc.

        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
 for a preview.

        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.

        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 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.

        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
        Here is my current take on the user category and classification
 of current bugs.


user debian-policy@lists.debian.org
usercategory issue-type [hidden]
 * Issue Type [tag=]
  + Normative [normative]
  + Informative [informative]
  + Packaging [packaging]
  + Unclassified []

usercategory issue-status [hidden]
 * Issue Status [tag=]
  + Issue Raised [issue]
  + Under Discussion [discussion]
  + Opinion Solicited [opinion]
  + Change Proposed [proposal]
  + Wording Proposed [wording]
  + Wording Seconded [seconded]
  + Wording Accepted [accepted]
  + Rejected [tag=rejected]
  + Unknown []

usercategory policy
 * status
 * issue-type
 * issue-status
 * severity
 * classification

usercategory old
 * status
 * severity
 * classification

 usertag 452393 + issue, normative

 usertag  89038 + issue, normative
 usertag 120418 + issue, normative
 usertag 122038 + issue, normative
 usertag 161912 + issue, normative
 usertag 186700 + issue, normative
 usertag 192571 + issue, normative
 usertag 215549 + issue, normative
 usertag 228692 + issue, normative
 usertag 263448 + issue, normative
 usertag 276160 + issue, normative
 usertag 291177 + issue, normative
 usertag 375502 + issue, normative
 usertag 392479 + issue, normative
 usertag 400322 + issue, normative
 usertag 402721 + issue, normative
 usertag 408500 + issue, normative
 usertag 412668 + issue, normative
 usertag 425523 + issue, normative, dpkg
 usertag 438492 + issue, normative, dubious
 usertag 442070 + issue, normative
 usertag 445203 + issue, normative
 usertag 446712 + issue, normative
 usertag 447231 + issue, normative
 usertag 452105 + issue, normative
 usertag 457364 + issue, normative

 usertag 403391 + discussion, normative

 usertag 374029 + discussion, normative

 usertag 391240 + discussion, normative

 usertag  99324 + discussion, normative, dubious
 usertag  99933 + discussion, normative
 usertag 160827 + discussion, normative
 usertag 169600 + discussion, normative, dubious
 usertag 181123 + discussion, normative
 usertag 184064 + discussion, normative
 usertag 188731 + discussion, normative
 usertag 203650 + discussion, normative, dubious
 usertag 212814 + discussion, normative
 usertag 224509 + discussion, normative
 usertag 232448 + discussion, normative
 usertag 248809 + discussion, normative
 usertag 253511 + discussion, normative, dubious
 usertag 291148 + discussion, normative
 usertag 291631 + discussion, normative
 usertag 295006 + discussion, normative, dubious
 usertag 299007 + discussion, normative, security, dubious
 usertag 331532 + discussion, normative, dubious
 usertag 338219 + discussion, normative
 usertag 367650 + discussion, normative, dubious
 usertag 381729 + discussion, normative, dubious
 usertag 391841 + discussion, normative
 usertag 397939 + discussion, normative
 usertag 399913 + discussion, normative
 usertag 400112 + discussion, normative
 usertag 401452 + discussion, normative
 usertag 403649 + discussion, normative, dpkg
 usertag 411510 + discussion, normative
 usertag 413353 + discussion, normative
 usertag 430649 + discussion, normative
 usertag 431109 + discussion, normative
 usertag 434651 + discussion, normative, dubious
 usertag 435476 + discussion, normative, dubious
 usertag 436419 + discussion, normative
 usertag 440420 + discussion, normative

 usertag 104373 + normative, proposal
 usertag 106073 + normative, proposal
 usertag 122817 + normative, proposal, dubious
 usertag 143941 + normative, proposal
 usertag 152955 + normative, proposal
 usertag 196367 + normative, proposal
 usertag 206684 + normative, proposal
 usertag 208010 + normative, proposal
 usertag 208011 + normative, proposal
 usertag 218893 + normative, proposal
 usertag 241333 + normative, proposal
 usertag 246016 + normative, proposal
 usertag 267142 + normative, proposal
 usertag 284340 + normative, proposal, dubious
 usertag 291460 + normative, proposal
 usertag 314808 + normative, proposal
 usertag 345619 + normative, proposal, dubious
 usertag 347581 + normative, proposal
 usertag 348336 + normative, proposal
 usertag 391836 + normative, proposal
 usertag 416450 + normative, proposal
 usertag 431813 + normative, proposal
 usertag 436105 + normative, proposal
 usertag 442134 + normative, proposal
 usertag 443334 + normative, proposal

 usertag 379150 + normative, wording, dpkg
 usertag 392362 + normative, wording

 usertag  65577 + normative, wording
 usertag 114920 + normative, wording
 usertag 172436 + normative, wording
 usertag 209008 + normative, wording
 usertag 250202 + normative, wording
 usertag 367984 + normative, wording

 usertag 455602 + informative, issue

 usertag 422552 + informative, discussion

 usertag 102213 + informative, discussion, dubious
 usertag 163666 + informative, discussion
 usertag 218897 + informative, discussion

 usertag 328951 + informative, proposal

 usertag 175202 + informative, proposal
 usertag 186102 + informative, proposal

 usertag  47438 + packaging
 usertag 175064 + packaging

 usertag 203098 + packaging

"If I ever get around to writing that language depompisifier, it will
change almost all occurences of the word "paradigm" into "example" or
"model." -- Herbie Blashtfalt
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: