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