Process.org

   1 # -*- mode: org; fill-column: 78 -*-
   2 #+STARTUP: showall
   3 #+STARTUP: lognotedone lognotestate
   4 #+OPTIONS: H:4 toc:2
   5 #+TITLE:  Debian Policy changes process
   6 #+AUTHOR: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava
   7 #+EMAIL: srivasta@debian.org
   8 #+OPTIONS:   H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:nil skip:t d:nil tags:not-in-toc
   9 #+LINK_HOME: http://wiki.debian.org/Teams/Policy
  10 #+LINK_UP: http://www.debian.org/
  11 #+LATEX_HEADER: \input{README-header.tex}
  12
  13 To introduce a change in the current DebianPolicy, the change proposal
  14 has to go through a certain process.
  15
  16 * Change Goals
  17
  18 + The change should be technically correct, and consistent with the
  19   rest of the policy document. This means no legislating the value of
  20   π. This also means that the proposed solution be known to work;
  21   iterative design processes do not belong in policy.
  22 + The change should not be too disruptive; if very many packages
  23   become instantly buggy, then instead there should be a transition
  24   plan. Exceptions should be rare (only if the current state is really
  25   untenable), and probably blessed by the TC.
  26 + The change has to be reviewed in depth, in the open, where any one
  27   may contribute; a publicly accessible, archived, open mailing list.
  28 + Proposal should be addressed in a timely fashion.
  29 + Any domain experts should be consulted, since not every policy
  30   mailing list subscriber is an expert on everything, including policy
  31   maintainers.
  32 + The goal is rough consensus on the change, which should not be hard
  33   if the matter is technical. Technical issues where there is no
  34   agreement should be referred to the TC; non-technical issues should
  35   be referred to the whole developer body, and perhaps general
  36   resolutions lie down that path.
  37 + Package maintainers whose packages may be impacted should have
  38   access to policy change proposals, even if they do not subscribe to
  39   policy mailing lists (policy gazette?).
  40
  41 * Current Process
  42
  43 Each suggested change goes through different states. These states are
  44 denoted through either usertags of the
  45 [[mailto:debian-policy@packages.debian.org][debian-policy@packages.debian.org]] user or, for patch, pending, and
  46 wontfix, regular tags.
  47
  48 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done][Current list of bugs]]
  49
  50 The Policy delegates are responsible for managing the tags on bugs and
  51 will update tags as new bugs are submitted or as activity happens on
  52 bugs. All Debian Developers should feel free to add the seconded tag
  53 as described below. Other tags should be changed with the coordination
  54 of the Policy Team.
  55
  56 ** State A: Issue raised
  57
  58 Detect need, like gaps/flaws in current policy, or a new rule should
  59 be added. Any user or developer may start this step. There is a
  60 decision point here, not all issues are in scope of policy.
  61 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue][TAG: issue]]
  62
  63 What needs to happen next: If this is in scope for Policy, discuss the
  64 issue and possible solutions, moving to the discussion tag, or if the
  65 matter is sufficiently clear, go directly to a proposal for how to
  66 address it, moving to the proposal tag. If this is not in scope for
  67 Policy, close the bug.
  68
  69 ** State B: Discussion
  70
  71 Discuss remedy. Alternate proposals. Discussion guided by
  72 delegates. There should be a clear time limit to this stage, but as
  73 yet we have not set one.
  74 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion][TAG: discussion]]
  75
  76 What needs to happen next: Reach a conclusion and consensus in the
  77 discussion and make a final proposal for what should be changed (if
  78 anything), moving to the proposal tag.
  79
  80 ** State C: Proposal
  81
  82 A final proposal has emerged from the discussion, and there is a rough
  83 consensus on how to proceed to resolve the issue.
  84 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal][TAG: proposal]]
  85
  86 What needs to happen next: Provided that the rough consensus persists,
  87 develop a patch against the current Policy document with specific
  88 wording of the change. Often this is done in conjunction with the
  89 proposal, in which case one may skip this step and move directly to
  90 patch tag.
  91
  92 ** State D: Wording proposed
  93
  94 A patch against the Policy document reflecting the consensus has been
  95 created and is waiting for formal seconds. The standard patch tag is
  96 used for this state, since it's essentially equivalent to the standard
  97 meaning of that tag.
  98 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch][TAG: patch]]
  99
 100 What needs to happen next: The proposal needs to be reviewed and
 101 seconded. Any Debian developer who agrees with the change and the
 102 conclusion of rough consensus from the discussion should say so in the
 103 bug log by seconding the proposal.
 104
 105 ** State E: Seconded
 106
 107 The proposal is signed off on by N Debian Developers. To start with,
 108 we're going with N=3, meaning that if three Debian Developers agree,
 109 not just with the proposal but with the conclusion that it reflects
 110 consensus and addresses the original issue -- it is considered
 111 eligible for inclusion in the next version of Policy. Since Policy is
 112 partly a technical project governance method, one must be a Debian
 113 Developer to formally second, although review and discussion is
 114 welcome from anyone. Once this tag has been applied, the bug is
 115 waiting for a Policy team member to apply the patch to the package
 116 repository.
 117 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded][TAG: seconded]]
 118
 119 What needs to happen next: A Policy maintainer does the final review
 120 and confirmation, and then applies the patch for the next Policy
 121 release.
 122
 123 This tag is not used very much because normally a Policy maintainer
 124 applies the patch and moves the proposal to the next state once enough
 125 seconds are reached.
 126
 127 ** State F: Accepted
 128
 129 Change accepted, will be in next upload. The standard pending tag is
 130 used for this state since it matches the regular meaning of
 131 pending.
 132 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=pending][TAG: pending]]
 133
 134 What needs to happen next: The bug is now in the waiting queue for the
 135 next Policy release, and there's nothing left to do except for upload
 136 a new version of Policy.
 137
 138 ** State G: Reject
 139
 140 Rejected proposals. The standard wontfix is used for this
 141 state. Normally, bugs in this state will not remain open; instead, a
 142 Policy team member will close them with an explanation. The submitter
 143 may then appeal to the tech-ctte if they so desire. Alternately,
 144 issues appealed to the tech-ctte may remain open with this tag while
 145 that appeal proceeds.
 146 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected][TAG: wontfix]]
 147
 148 We may use one of the following tags here, but to date we have only
 149 used dubious and ctte. It's not clear whether we need more tags for
 150 this tage.
 151
 152 + *dubious* :: Not a policy matter
 153 + *ctte* :: Referred to the Technical Committee (tech-ctte)
 154 + *devel* :: Referred to the developer body
 155 + *delegate* :: Rejected by a Policy delegate
 156 + *obsolete* :: The proposal timed out without a conclusion
 157
 158 What needs to happen next: The bug should be closed once a final
 159 resolution is reached, or retagged to an appropriate state if that
 160 final resolution reverses the decision to reject the proposal.
 161
 162 * Other Tags
 163
 164 All Policy bugs are additionally categorized by class of bug.
 165
 166 The normative tag is used for bugs that make normative changes to
 167 Policy, meaning that the dictates of Policy will change in some
 168 fashion as part of the resolution of the bug if the proposal is
 169 accepted. The full process is followed for such bugs.
 170 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative][TAG: normative]]
 171
 172 The informative tag is used for bugs about wording issues, typos,
 173 informative footnotes, or other changes that do not affect the formal
 174 dictates of Policy, just the presentation. The same tags are used for
 175 these bugs for convenience, but the Policy maintainers may make
 176 informative changes without following the full process. Informative
 177 bugs fall under their discretion.
 178 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative][TAG: informative]]
 179
 180 The packaging tag is used for bugs about the packaging and build
 181 process of the debian-policy Debian package. These bugs do not follow
 182 the normal process and will not have the other tags except for pending
 183 and wontfix (used with their normal meanings).
 184 [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging][TAG: packaging]]