Trac Usage Conventions

[Michael Stone]

Dear world,

In yesterday's software status meeting, we formulated some conventions
for using Trac for the next few months. They are:

1. The release team - presently including me, Greg Smith, and Kim Quirk
   will occasionally tag a ticket as 'blocks:8.2.0' to indicate that it
   blocks the 8.2.0 release. Such tickets will be understood to be part
   of our release criteria. If you think that a ticket should be so
   marked, please poke us until we deal with it.

2. Greg will record customer preference data according to whatever means
   he sees fit and will inform us of these data in regular meetings.

3. Kim wants a way to keep track of 'critical' bugs. Michael defined
   'critical bugs' as those bugs which receive the most careful oversight
   by the release team. Shortly, the release team will invent a
   convention for identifying such bugs which permits their inclusion in
   reports. These reports will be listed on the frontpage of Trac.
  
4. People should indicate the release they _wish_ that changes would
   land in via the Milestone field.

5. People should indicate their confidence that the changes _will_ land
   by tagging tickets with strings like:

      8.2.0:+ -- means that the change is "within reach" or, preferably,
      has been included in a dist-olpc3-updates series build.
                 
      8.2.0:? -- the change is "in danger of missing the boat".

      8.2.0:- -- the change is unlikely to be ready for release

   (NB: Please be conservative in tagging things <rel>:+.)

6. When it's unambiguous, people should attach test results to tickets
   with tags like:

      joyride-2027:-  --  the issue persists in joyride-2027
      joyride-2029:+  --  the issue was not reproducible in joyride-2027

   If appropriate, please also describe the test procedure that was
   executed to generate the result.

7. We have added a 'Needs Action' field to Trac with several states for
   common actions (and various kinds of ignorance of what action is
   needed.) Please use it. Let us know if we need to change the set of
   actions.

8. The 'priority' field is a place for component maintainers to say what
   they think is important; however, we expect that our regular IRC
   meetings and emails will be the primary vehicle for communicating
   day-to-day priority information.

   (NB: We may revisit the priority information decisions.)

Please comment freely.

Regards,

Michael