Process.html

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   3                "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   4 <html xmlns="http://www.w3.org/1999/xhtml"
   5 lang="en" xml:lang="en">
   6 <head>
   7 <title>Debian Policy changes process</title>
   8 <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
   9 <meta name="generator" content="Org-mode"/>
  10 <meta name="generated" content="2010-06-04 09:41:24 PDT"/>
  11 <meta name="author" content="Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava"/>
  12 <meta name="description" content=""/>
  13 <meta name="keywords" content=""/>
  14
  15 <style type="text/css">
  16   html { font-family: Times, serif; font-size: 12pt; }
  17   .title  { text-align: center; }
  18   p.verse { margin-left: 3% }
  19   pre {
  20         border: 1pt solid #AEBDCC;
  21         color: #000000;
  22         background-color: LightSlateGray;
  23         padding: 5pt;
  24         font-family: "Courier New", courier, monospace;
  25         font-size: 90%;
  26         overflow:auto;
  27   }
  28   dt { font-weight: bold; }
  29   div.figure { padding: 0.5em; }
  30   div.figure p { text-align: center; }
  31   .linenr { font-size:smaller }
  32   .code-highlighted {background-color:#ffff00;}
  33   .org-info-js_info-navigation { border-style:none; }
  34   #org-info-js_console-label { font-size:10px; font-weight:bold;
  35                                white-space:nowrap; }
  36   .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
  37                                  font-weight:bold; }
  38
  39   body {
  40    color: black;
  41    background-color: white;
  42    font-family: Palatino, "Palatino Linotype", "Hoefler Text", "Times New Roman", Times, Georgia, Utopia, serif;
  43   }
  44   .org-agenda-date          { color: #87cefa;    }
  45   .org-agenda-structure     { color: #87cefa;    }
  46   .org-scheduled            { color: #98fb98;    }
  47   .org-scheduled-previously { color: #ff7f24;    }
  48   .org-scheduled-today      { color: #98fb98;    }
  49   .org-tag                  { font-weight: bold; }
  50   .org-todo                 {
  51     color: #ffc0cb;
  52     font-weight: bold;
  53   }
  54
  55   a:hover { text-decoration: underline; }
  56   .todo  { font-weight:bold; }
  57   .done { font-weight:bold; }
  58   .TODO { color:red; }
  59   .WAITING { color:orange; }
  60   .DONE { color:green; }
  61   .timestamp { color: grey }
  62   .timestamp-kwd { color: CadetBlue }
  63   .tag { background-color:lightblue; font-weight:normal }
  64   .target { background-color: lavender; }
  65 table {
  66         border-collapse: collapse; /*separate; */
  67         border: outset 3pt;
  68         border-spacing: 0pt;
  69         /* border-spacing: 5pt; */
  70         }
  71 table td             { vertical-align: top; border: 1px solid; }
  72 table th             { vertical-align: top; border: 2px solid; }
  73 </style>
  74 <script ="text/javascript" language="JavaScript" src="/styles/org-info.js"></script>
  75 <script type="text/javascript" language="JavaScript">
  76 /* <![CDATA[ */
  77 org_html_manager.set("LOCAL_TOC", 0);
  78 org_html_manager.set("VIEW_BUTTONS", 1);
  79 org_html_manager.set("VIEW", "info");
  80 org_html_manager.set("TOC", 1);
  81 org_html_manager.set("MOUSE_HINT", "underline"); // could be a background-color like #eeeeee
  82 org_html_manager.setup ();
  83 /* ]]> */
  84 </script>
  85
  86 <script type="text/javascript">
  87 <!--/*--><![CDATA[/*><!--*/
  88  function CodeHighlightOn(elem, id)
  89  {
  90    var target = document.getElementById(id);
  91    if(null != target) {
  92      elem.cacheClassElem = elem.className;
  93      elem.cacheClassTarget = target.className;
  94      target.className = "code-highlighted";
  95      elem.className   = "code-highlighted";
  96    }
  97  }
  98  function CodeHighlightOff(elem, id)
  99  {
 100    var target = document.getElementById(id);
 101    if(elem.cacheClassElem)
 102      elem.className = elem.cacheClassElem;
 103    if(elem.cacheClassTarget)
 104      target.className = elem.cacheClassTarget;
 105  }
 106 /*]]>*///-->
 107 </script>
 108 </head>
 109 <body>
 110 <div id="content">
 111 <div id="org-div-home-and-up" style="text-align:right;font-size:70%;white-space:nowrap;">
 112  <a accesskey="h" href="http://www.debian.org/"> UP </a>
 113  |
 114  <a accesskey="H" href="http://wiki.debian.org/Teams/Policy"> HOME </a>
 115 </div>
 116
 117 <h1 class="title">Debian Policy changes process</h1>
 118
 119
 120 <div id="outline-container-1" class="outline-2">
 121 <h2 id="sec-1">Change Goals </h2>
 122 <div class="outline-text-2" id="text-1">
 123
 124
 125 <ul>
 126 <li>
 127 The change should be technically correct, and consistent with the
 128 rest of the policy document. This means no legislating the value of
 129 π. This also means that the proposed solution be known to work;
 130 iterative design processes do not belong in policy.
 131 </li>
 132 <li>
 133 The change should not be too disruptive; if very many packages
 134 become instantly buggy, then instead there should be a transition
 135 plan. Exceptions should be rare (only if the current state is really
 136 untenable), and probably blessed by the TC.
 137 </li>
 138 <li>
 139 The change has to be reviewed in depth, in the open, where any one
 140 may contribute; a publicly accessible, archived, open mailing list.
 141 </li>
 142 <li>
 143 Proposal should be addressed in a timely fashion.
 144 </li>
 145 <li>
 146 Any domain experts should be consulted, since not every policy
 147 mailing list subscriber is an expert on everything, including policy
 148 maintainers.
 149 </li>
 150 <li>
 151 The goal is rough consensus on the change, which should not be hard
 152 if the matter is technical. Technical issues where there is no
 153 agreement should be referred to the TC; non-technical issues should
 154 be referred to the whole developer body, and perhaps general
 155 resolutions lie down that path.
 156 </li>
 157 <li>
 158 Package maintainers whose packages may be impacted should have
 159 access to policy change proposals, even if they do not subscribe to
 160 policy mailing lists (policy gazette?).
 161
 162 </li>
 163 </ul>
 164 </div>
 165
 166 </div>
 167
 168 <div id="outline-container-2" class="outline-2">
 169 <h2 id="sec-2">Current Process </h2>
 170 <div class="outline-text-2" id="text-2">
 171
 172
 173 <p>
 174 Each suggested change goes through different states. These states are
 175 denoted through either usertags of the
 176 <a href="mailto:debian-policy@packages.debian.org">debian-policy@packages.debian.org</a> user or, for patch, pending, and
 177 wontfix, regular tags.
 178 </p>
 179 <p>
 180 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done">Current list of bugs</a>
 181 </p>
 182 <p>
 183 The Policy delegates are responsible for managing the tags on bugs and
 184 will update tags as new bugs are submitted or as activity happens on
 185 bugs. All Debian Developers should feel free to add the seconded tag
 186 as described below. Other tags should be changed with the coordination
 187 of the Policy Team.
 188 </p>
 189
 190 </div>
 191
 192 <div id="outline-container-2_1" class="outline-3">
 193 <h3 id="sec-2_1">State A: Issue raised </h3>
 194 <div class="outline-text-3" id="text-2_1">
 195
 196
 197 <p>
 198 Detect need, like gaps/flaws in current policy, or a new rule should
 199 be added. Any user or developer may start this step. There is a
 200 decision point here, not all issues are in scope of policy.
 201 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;tag=issue">TAG: issue</a>
 202 </p>
 203 <p>
 204 What needs to happen next: If this is in scope for Policy, discuss the
 205 issue and possible solutions, moving to the discussion tag, or if the
 206 matter is sufficiently clear, go directly to a proposal for how to
 207 address it, moving to the proposal tag. If this is not in scope for
 208 Policy, close the bug.
 209 </p>
 210 </div>
 211
 212 </div>
 213
 214 <div id="outline-container-2_2" class="outline-3">
 215 <h3 id="sec-2_2">State B: Discussion </h3>
 216 <div class="outline-text-3" id="text-2_2">
 217
 218
 219 <p>
 220 Discuss remedy. Alternate proposals. Discussion guided by
 221 delegates. There should be a clear time limit to this stage, but as
 222 yet we have not set one.
 223 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=discussion">TAG: discussion</a>
 224 </p>
 225 <p>
 226 What needs to happen next: Reach a conclusion and consensus in the
 227 discussion and make a final proposal for what should be changed (if
 228 anything), moving to the proposal tag.
 229 </p>
 230 </div>
 231
 232 </div>
 233
 234 <div id="outline-container-2_3" class="outline-3">
 235 <h3 id="sec-2_3">State C: Proposal </h3>
 236 <div class="outline-text-3" id="text-2_3">
 237
 238
 239 <p>
 240 A final proposal has emerged from the discussion, and there is a rough
 241 consensus on how to proceed to resolve the issue.
 242 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=proposal">TAG: proposal</a>
 243 </p>
 244 <p>
 245 What needs to happen next: Provided that the rough consensus persists,
 246 develop a patch against the current Policy document with specific
 247 wording of the change. Often this is done in conjunction with the
 248 proposal, in which case one may skip this step and move directly to
 249 patch tag.
 250 </p>
 251 </div>
 252
 253 </div>
 254
 255 <div id="outline-container-2_4" class="outline-3">
 256 <h3 id="sec-2_4">State D: Wording proposed </h3>
 257 <div class="outline-text-3" id="text-2_4">
 258
 259
 260 <p>
 261 A patch against the Policy document reflecting the consensus has been
 262 created and is waiting for formal seconds. The standard patch tag is
 263 used for this state, since it's essentially equivalent to the standard
 264 meaning of that tag.
 265 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=patch">TAG: patch</a>
 266 </p>
 267 <p>
 268 What needs to happen next: The proposal needs to be reviewed and
 269 seconded. Any Debian developer who agrees with the change and the
 270 conclusion of rough consensus from the discussion should say so in the
 271 bug log by seconding the proposal.
 272 </p>
 273 </div>
 274
 275 </div>
 276
 277 <div id="outline-container-2_5" class="outline-3">
 278 <h3 id="sec-2_5">State E: Seconded </h3>
 279 <div class="outline-text-3" id="text-2_5">
 280
 281
 282 <p>
 283 The proposal is signed off on by N Debian Developers. To start with,
 284 we're going with N=3, meaning that if three Debian Developers agree,
 285 not just with the proposal but with the conclusion that it reflects
 286 consensus and addresses the original issue &ndash; it is considered
 287 eligible for inclusion in the next version of Policy. Since Policy is
 288 partly a technical project governance method, one must be a Debian
 289 Developer to formally second, although review and discussion is
 290 welcome from anyone. Once this tag has been applied, the bug is
 291 waiting for a Policy team member to apply the patch to the package
 292 repository.
 293 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=seconded">TAG: seconded</a>
 294 </p>
 295 <p>
 296 What needs to happen next: A Policy maintainer does the final review
 297 and confirmation, and then applies the patch for the next Policy
 298 release.
 299 </p>
 300 <p>
 301 This tag is not used very much because normally a Policy maintainer
 302 applies the patch and moves the proposal to the next state once enough
 303 seconds are reached.
 304 </p>
 305 </div>
 306
 307 </div>
 308
 309 <div id="outline-container-2_6" class="outline-3">
 310 <h3 id="sec-2_6">State F: Accepted </h3>
 311 <div class="outline-text-3" id="text-2_6">
 312
 313
 314 <p>
 315 Change accepted, will be in next upload. The standard pending tag is
 316 used for this state since it matches the regular meaning of
 317 pending.
 318 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=pending">TAG: pending</a>
 319 </p>
 320 <p>
 321 What needs to happen next: The bug is now in the waiting queue for the
 322 next Policy release, and there's nothing left to do except for upload
 323 a new version of Policy.
 324 </p>
 325 </div>
 326
 327 </div>
 328
 329 <div id="outline-container-2_7" class="outline-3">
 330 <h3 id="sec-2_7">State G: Reject </h3>
 331 <div class="outline-text-3" id="text-2_7">
 332
 333
 334 <p>
 335 Rejected proposals. The standard wontfix is used for this
 336 state. Normally, bugs in this state will not remain open; instead, a
 337 Policy team member will close them with an explanation. The submitter
 338 may then appeal to the tech-ctte if they so desire. Alternately,
 339 issues appealed to the tech-ctte may remain open with this tag while
 340 that appeal proceeds.
 341 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=rejected">TAG: wontfix</a>
 342 </p>
 343 <p>
 344 We may use one of the following tags here, but to date we have only
 345 used dubious and ctte. It's not clear whether we need more tags for
 346 this tage.
 347 </p>
 348 <dl>
 349 <dt><b>dubious</b></dt><dd>
 350 Not a policy matter
 351 </dd>
 352 <dt><b>ctte</b></dt><dd>
 353 Referred to the Technical Committee (tech-ctte)
 354 </dd>
 355 <dt><b>devel</b></dt><dd>
 356 Referred to the developer body
 357 </dd>
 358 <dt><b>delegate</b></dt><dd>
 359 Rejected by a Policy delegate
 360 </dd>
 361 <dt><b>obsolete</b></dt><dd>
 362 The proposal timed out without a conclusion
 363
 364 </dd>
 365 </dl>
 366
 367 <p>What needs to happen next: The bug should be closed once a final
 368 resolution is reached, or retagged to an appropriate state if that
 369 final resolution reverses the decision to reject the proposal.
 370 </p>
 371 </div>
 372 </div>
 373
 374 </div>
 375
 376 <div id="outline-container-3" class="outline-2">
 377 <h2 id="sec-3">Other Tags </h2>
 378 <div class="outline-text-2" id="text-3">
 379
 380
 381 <p>
 382 All Policy bugs are additionally categorized by class of bug.
 383 </p>
 384 <p>
 385 The normative tag is used for bugs that make normative changes to
 386 Policy, meaning that the dictates of Policy will change in some
 387 fashion as part of the resolution of the bug if the proposal is
 388 accepted. The full process is followed for such bugs.
 389 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=normative">TAG: normative</a>
 390 </p>
 391 <p>
 392 The informative tag is used for bugs about wording issues, typos,
 393 informative footnotes, or other changes that do not affect the formal
 394 dictates of Policy, just the presentation. The same tags are used for
 395 these bugs for convenience, but the Policy maintainers may make
 396 informative changes without following the full process. Informative
 397 bugs fall under their discretion.
 398 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=informative">TAG: informative</a>
 399 </p>
 400 <p>
 401 The packaging tag is used for bugs about the packaging and build
 402 process of the debian-policy Debian package. These bugs do not follow
 403 the normal process and will not have the other tags except for pending
 404 and wontfix (used with their normal meanings).
 405 <a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&amp;pend-exc=done&amp;tag=packaging">TAG: packaging</a>
 406 </p></div>
 407 </div>
 408 <div id="postamble">
 409 <p class="author"> Author: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava
 410 </p>
 411 <p class="date"> Date: 2010-06-04 09:41:24 PDT</p>
 412 <p class="creator">HTML generated by org-mode 6.36c in emacs 23</p>
 413 </div>
 414 </div>
 415 </body>
 416 </html>