[or-cvs] r9606: Clarify some aspects of proposal process, based on questions (in tor/trunk: . doc/spec/proposals)

[nickm at seul.org]

Author: nickm
Date: 2007-02-20 18:22:33 -0500 (Tue, 20 Feb 2007)
New Revision: 9606

Modified:
   tor/trunk/
   tor/trunk/doc/spec/proposals/001-process.txt
Log:
 r12276 at Kushana:  nickm | 2007-02-20 18:16:48 -0500
 Clarify some aspects of proposal process, based on questions from phobos.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r12276] on c95137ef-5f19-0410-b913-86e773d04f59

Modified: tor/trunk/doc/spec/proposals/001-process.txt
===================================================================
--- tor/trunk/doc/spec/proposals/001-process.txt	2007-02-20 23:22:27 UTC (rev 9605)
+++ tor/trunk/doc/spec/proposals/001-process.txt	2007-02-20 23:22:33 UTC (rev 9606)
@@ -45,7 +45,8 @@
    Once it's fleshed out enough, it becomes a proposal.
 
    Like an RFC, every proposal gets a number.  Unlike RFCs, proposals can
-   change over time and keep the same number.  The history for each proposal
+   change over time and keep the same number, until they are finally
+   accepted or rejected.  The history for each proposal
    will be stored in the Tor Subversion repository.
 
    Once a proposal is in the repository, we should discuss and improve it
@@ -55,7 +56,8 @@
    remain the canonical documentation for the Tor protocol: no proposal is
    ever the canonical documentation for an implemented feature.
 
-   {It's still okay to make small changes to the spec if the code can be
+   {It's still okay to make small changes directly to the spec if the code
+   can be
    written more or less immediately, or cosmetic changes if no code change is
    required.  This document reflects the current developers' _intent_, not
    a permanent promise to always use this process in the future: we reserve
@@ -66,9 +68,13 @@
 
   Once an idea has been proposed on the development list, a properly formatted
   (see below) draft exists, and rough consensus withing the active development
-  community exists that this idea warrants consideration the proposal editor
-  will official add the proposal.
+  community exists that this idea warrants consideration, the proposal editor
+  will officially add the proposal.
 
+  To get your proposal in, send it to or-dev.
+
+  The current proposal editor is Nick Mathewson.
+
 What should go in a proposal:
 
    Every proposal should have a header containing these fields:
@@ -82,7 +88,7 @@
    After the Overview, the proposal becomes more free-form.  Depending on its
    the length and complexity, the proposal can break into sections as
    appropriate, or follow a short discursive format.  Every proposal should
-   contain at least the following information before it can be "ACCEPTED",
+   contain at least the following information before it is "ACCEPTED",
    though the information does not need to be in sections with these names.
 
       Motivation: What problem is the proposal trying to solve?  Why does
@@ -127,15 +133,21 @@
    Open: A proposal under discussion.
 
    Accepted: The proposal is complete, and we intend to implement it.
+      After this point, substantive changes to the proposal should be
+      avoided, and regarded as a sign of the process having failed
+      somewhere.
 
-   Finished: The proposal has been accepted and implemented.
+   Finished: The proposal has been accepted and implemented.  After this
+      point, the proposal should not be changed.
 
    Closed: The proposal has been accepted, implemented, and merged into the
-      main specification documents.
+      main specification documents.  The proposal should not be changed after
+      this point.
 
    Rejected: We're not going to implement the feature as described here,
       though we might do some other version.  See comments in the document
-      for details.
+      for details.  The proposal should not be changed after this point;
+      to bring up some other version of the idea, write a new proposal.
 
    Needs-Revision: The idea for the proposal is a good one, but the proposal
       as it stands has serious problems that keep it from being accepted.