From f8be22e03da62558cb26d309d27f1ecb90e01ed2 Mon Sep 17 00:00:00 2001
From: tchernobog <tchernobog@3ecf2c5c-341e-0410-92b4-d18e462d057c>
Date: Tue, 7 Feb 2006 12:25:55 +0000
Subject: [PATCH] - Add subsection about the anomaly solving process - Fix
 example about how to document C++ classes - Fix note about non-const static
 class members

git-svn-id: svn://svn.gna.org/svn/sgpemv2/trunk@297 3ecf2c5c-341e-0410-92b4-d18e462d057c
---
 doc/sgpem2dman.texi | 75 ++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 64 insertions(+), 11 deletions(-)

diff --git a/doc/sgpem2dman.texi b/doc/sgpem2dman.texi
index 7cc2884..78c3ae9 100644
--- a/doc/sgpem2dman.texi
+++ b/doc/sgpem2dman.texi
@@ -97,6 +97,11 @@ Free Documentation License''.
 
 @table @strong
 
+@item 2006, February 7th, @r{--- Matteo Settenvini}
+Added subsection about the anomaly solving process.
+Fixed C++ code conventions about how to document classes,
+and the note about static non-const members in classes.
+
 @item 2006, February 2nd, @r{--- Luca Vezzaro}
 Updated coding style with a point on static non-POD
 objects.
@@ -442,20 +447,24 @@ These are used @strong{before} reaching a resolution:
 
       @item UNCONFIRMED
       This bug has recently been added to the database. Nobody has validated that 
-      this bug is true. Users who have the "canconfirm" permission set may confirm 
-      this bug, changing its state to @samp{NEW}. Or, it may be directly resolved 
-      and marked @samp{RESOLVED}. 
+      this bug is true. The manager will usually confirm this bug, changing its state 
+      to @samp{NEW}, but in case the bug existance is quite clear, any stakeholder
+      can mark it as such. 
+
+      The anomaly may be marked also @samp{RESOLVED} by the manager, if it is
+      @samp{INVALID}, @samp{DUPLICATE} or so on, but @strong{not} 
+      @samp{RESOLVED FIXED}.
       
       @item NEW
       This bug has recently been added to the assignee's list of bugs and must be 
       processed. Bugs in this state may be accepted, and become @samp{ASSIGNED}, 
-      passed on to someone else, and remain @samp{NEW}, or resolved and marked 
-      @samp{RESOLVED}. 
+      passed on to someone else, and remain @samp{NEW}, or it can be 
+      made also @samp{RESOLVED}.
 
       @item ASSIGNED
       This bug is not yet resolved, but is assigned to the proper person. From here 
-      bugs can be given to another person and become @samp{NEW}, or resolved and 
-      become @samp{RESOLVED}. 
+      bugs can be given to another person and become @samp{ASSIGNED} with a different
+      assignee, or resolved and become @samp{RESOLVED}. 
       
       @item REOPENED
       This bug was once resolved, but the resolution was deemed incorrect. For example, 
@@ -552,6 +561,48 @@ Usually it's the same person as the assignee.
 
 @end table
 
+@c % ----- new subsection
+
+@subsection Roles solving anomalies
+
+When solving an anomaly, we mostly follow the pattern therein explained:
+
+@enumerate
+
+@item
+@b{Anybody}, having any role, can report an anomaly about the work done by someone else. 
+It doesn't make a lot of sense reporting a bug about what you're doing: you just 
+fix it and carry on.
+
+It may be sensible to report problems about your work only if you discover them 
+in a second moment, when you don't cover the same role anymore, so the assignee
+would be different by the reporter.
+
+@item
+The discussion starts. Usually the verifier will check the anomaly exists, but
+if enough people confirm the bug, the @b{manager} can decide to mark the bug as 
+@samp{NEW} as well.
+
+@item
+Once it is clear who's the responsible for fixing the anomaly, the @b{manager}
+assign the bug to them, marking it as @samp{ASSIGNED}.
+
+@item
+A fix/patch may come up from different sources, even by the reporter, 
+but only the @b{assignee} can apply it to the tree and mark the bug as 
+@samp{SOLVED}. They take full responsability of the fix.
+
+@item
+The @b{verifier} does the needed @acronym{QA,Quality Assurance}, and then either
+reopens the bug or marks it as @samp{VERIFIED}.
+
+@item
+When and only if the product ships, a @samp{VERIFIED} anomaly may
+become @samp{CLOSED}, by hand of the @b{manager}.
+
+
+@end enumerate
+
 @c % --------------------------------------------------
 
 @node    Coding style, Committing changes, Writing documentation, Top
@@ -725,8 +776,10 @@ Put incomplete class declarations before their interface,
 documenting it. For example:
 @example 
 @verbatim
-//! I'm a useless class
-/** This class is completely useless. */
+/** \brief I'm a useless class
+ *
+ *  This class is completely useless.
+ */
 class C;
       // [...] 
 
@@ -744,7 +797,7 @@ follow a common model. Try to adhere to it
 by looking at existing headers. Document them 
 fully, even if it is tedious, using a 
 Doxygen-like syntax. The payback will be 
-high, I assure you.
+high, we assure you.
 
 @item
 Class names are composed of UpperCamelCase words.
@@ -948,7 +1001,7 @@ Please follow this order when declaring a class interface:
        Variable data members
 
        @end enumerate
-Static non-const data members shouldn't exist.
+Static non-const public data members shouldn't exist.
 Nested classes go declared @strong{outside} their
 containing class. For example:
 @example