[Gzz-commits] gzz/doc/pegboard/201 PEG_201.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Tuomas J. Lukka <address@hidden>        02/11/08 08:37:04

Modified files:
        doc/pegboard/201: PEG_201.rst 

Log message:
        Comments about issues

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/201/PEG_201.rst.diff?tr1=1.7&tr2=1.8&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/201/PEG_201.rst
diff -u gzz/doc/pegboard/201/PEG_201.rst:1.7 
gzz/doc/pegboard/201/PEG_201.rst:1.8
--- gzz/doc/pegboard/201/PEG_201.rst:1.7        Thu Nov  7 04:33:31 2002
+++ gzz/doc/pegboard/201/PEG_201.rst    Fri Nov  8 08:37:04 2002
@@ -4,8 +4,8 @@
 
 :Authors:  Tuomas Lukka
 :Stakeholders: Asko Soukka
-:Date:     $Date: 2002/11/07 09:33:31 $
-:Revision: $Revision: 1.7 $
+:Date:     $Date: 2002/11/08 13:37:04 $
+:Revision: $Revision: 1.8 $
 :Status:   Incomplete
 
 This META-PEG deals with formatting PEGs.
@@ -31,8 +31,31 @@
        at any other point. Once an issue is resolved, the resolution
        and its rationale should be here.
 
-       NOTE: PEGs should not be accepted as long as there are 
-       unresolved issues.
+       Issues should be clear **questions** which need answers.
+       "I'm not sure about X." would be much better phrased as
+       "Should we do X?". That way there is a clear question,
+       to which we are seeking a simple answer.
+
+       Resolutions of issues should always contain reasoning
+       behind them::
+
+           - should we do X?
+
+               RESOLVED: No
+
+       is not good. Should be::
+
+           - should we do X?
+
+               RESOLVED: No, since that would interfere with Y.
+
+       Even ::
+
+           - should we do X?
+
+               RESOLVED: No, not yet
+
+       is much better, since it at least gives more information.
 
     - Do we need the Scope and Type fields?
 
@@ -45,6 +68,10 @@
 When the PEG seems ready for review, it should be made Current and
 posted to gzz-dev. At this point, the PEG may still be edited
 in response to comments from the list.
+
+**NOTE**: PEGs should not be made Current as long as there are unresolved
+issues. If the responses from the list raise issues that cannot be immediately
+resolved, the PEG should be put into Incomplete state again.
 
 At some point after this, the architect (tjl) will make a decision
 to either accept, force revision, declare rejected, or declare