r77 - /web/deps/dep0.mdwn
zack at users.alioth.debian.org
zack at users.alioth.debian.org
Sun Jul 26 17:25:50 UTC 2009
Author: zack
Date: Sun Jul 26 17:25:49 2009
New Revision: 77
URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=77
Log:
* Re-word state description: describe separately states and
transitions.
* Rename "DROPPED" status to "REJECTED"; inhibit "resurrection" of
REJECTED DEPs.
Modified:
web/deps/dep0.mdwn
Modified: web/deps/dep0.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep0.mdwn?rev=77&op=diff
==============================================================================
--- web/deps/dep0.mdwn (original)
+++ web/deps/dep0.mdwn Sun Jul 26 17:25:49 2009
@@ -3,15 +3,15 @@
Title: Introducing Debian Enhancement Proposals (DEPs)
DEP: 0
State: DRAFT
- Date: 2008-05-29
+ Date: 2009-07-26
Drivers: Stefano Zacchiroli <zack at debian.org>,
Adeodato Simó <dato at net.com.org.es>,
Lars Wirzenius <liw at iki.fi>
URL: http://dep.debian.net/deps/dep0
License: http://www.jclark.com/xml/copying.txt
Abstract:
- Workflow for managing discussions about improvements to Debian and
- archiving their outcomes.
+ Workflow for managing discussions about improvements to Debian
+ and archiving their outcomes.
Introduction
@@ -107,51 +107,89 @@
Proposal states
---------------
-The proposal goes through several states over its lifetime. The ideal
-progression is DRAFT -> CANDIDATE -> ACCEPTED, but reality requires a
-couple of other states as well.
-
-#### DRAFT: discussion until (rough) consensus
-
- * every new proposal starts as a DRAFT
- * anyone can propose a draft
- * each draft has a number (next free one from document index)
- * normal changes happen in this period
- * drafts should include extra criteria for success (in addition to
- having obtained rough consensus, see below), that is, for moving to
- the ACCEPTED state
-
-#### CANDIDATE: implementation + testing
-
- * consensus exists for what should be done, and how it should be done
- * agreement needs to be expressed by all affected parties, not just the
- drivers; silence is not agreement, but unanimity is not required, either
- * implementation can of course start earlier
- * changes in this period are primarily based on feedback from implementation
- * this period must be long enough that there is a consensus that the
- enhancement works (on the basis of implementation evaluation)
-
-#### ACCEPTED: integrate to policy/devref/elsewhere (if applicable)
-
- * consensus exists that the implementation has been a success
- * also, the final version of the document is archived in a central place
- (vcs on alioth, plus web page generated from that), even if integrated
- to other documents as well
-
-#### DROPPED: no further action needed
-
- * the drivers are no longer interested in pursuing the DEP
- * if there are no modifications to a DEP in DRAFT state for six months,
- or there is a consensus that the implementation of a DEP in
- CANDIDATE state has been abandoned, the DEP is moved to DROPPED
- state (from which it can be resurrected by moving to DRAFT stage
- again)
-
-#### OBSOLETE: no longer relevant
-
- * for example, when a new revision (as a new DEP) gets accepted, the
- old one will move to OBSOLETE state, and will be modified to refer
- to the new one
+A given DEP can be in one of the following *states*:
+
+* DRAFT
+* CANDIDATE
+* ACCEPTED
+* REJECTED
+* OBSOLETE
+
+The ideal progression of states is DRAFT -> CANDIDATE -> ACCEPTED, but
+reality requires a couple of other states and transitions as well.
+
+### DRAFT state: discussion
+
+* every new proposal starts as a DRAFT
+* anyone can propose a draft
+* each draft has a number (next free one from document index)
+* normal discussion and changes to the text happen in this state
+* drafts should include *extra* criteria for success (in addition to
+ having obtained consensus, see below), that is, requirements to
+ finally become ACCEPTED
+
+#### DRAFT -> CANDIDATE: rough consensus
+
+In order for a DEP to become CANDIDATE, the following condition should
+be met:
+
+* consensus exists for *what* should be done, and *how* it should be
+ done (agreement needs to be expressed by all affected parties, not
+ just the drivers; silence is not agreement, but unanimity is not
+ required, either)
+
+### CANDIDATE: implementation + testing
+
+The CANDIDATE state is meant to prove, via a suitable implementation
+and its testing, that a given DEP is feasible.
+
+* of course, implementation can start in earlier states
+* changes to the text can happen also in this period, primarily based
+ on feedback from implementation
+* this period must be long enough that there is consensus that the
+ enhancement works (on the basis of implementation evaluation)
+* since DEP are not necessarily technical, "implementation" does not
+ necessarily mean coding
+
+#### CANDIDATE -> ACCEPTED: working implementation
+
+In order for a DEP to become ACCEPTED, the following condition should
+be met:
+
+* consensus exists that the implementation has been a success
+
+### ACCEPTED: have fun
+
+Once accepted:
+
+* the final version of the DEP text is archived in a central place
+ (VCS on alioth, plus web page generated from that) for future
+ reference
+* if applicable, the proposed DEP change is integrated into
+ authoritative texts such as policy, developer's reference, etc.
+
+#### {DRAFT, CANDIDATE} -> REJECTED
+
+A DEP can become REJECTED in the following cases:
+
+* the drivers are no longer interested in pursuing the DEP and
+ explicitly acknowledge so
+* there are no modifications to a DEP in DRAFT state for 6 months or
+ more
+* there is no consensus that the implementation of a DEP in CANDIDATE
+ state is working satisfactorily
+
+#### ACCEPTED -> OBSOLETE: no longer relevant
+
+A DEP can become OBSOLETE when it is no longer relevant, for example:
+
+* a new DEP gets accepted overriding previous DEPs (in that case the
+ new DEP should refer to the one it OBSOLETE-s)
+* the object of the enhancement is no longer in use
+
+### {REJECTED, OBSOLETE}
+
+In one of these states, no further actions are needed.
What the drivers should do
@@ -320,6 +358,13 @@
Changes
-------
+* 2009-07-26:
+ [ Stefano Zacchiroli ]
+ * Re-word state description: describe separately states and
+ transitions.
+ * Rename "DROPPED" status to "REJECTED"; inhibit "resurrection" of
+ REJECTED DEPs.
+
* 2008-06-12:
[ Lars Wirzenius ]
* Added a recommendation for the Expat license for new DEPs.
More information about the dep-commits
mailing list