Process.txt

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