[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

TC mailing list and BTS usage

Now that we are dealing with a number of issues simultaneously, and
all getting a number of copies of lots of messages, I think we need to
think about our workflow a bit better.

We would like to
 - avoid spamming an existing bug with our deliberations (in
   particular, that makes it difficult to reassign the bug
   back usefully since the history will be obscured by a giant
   email thread)
 - allow people to subscribe to only some of the issues
   being discussed
 - organise the discussion in a way that makes it possible to
   find all of it easily without having to deal with multiple
   varying subject line keywords
 - everyone to get as few redundant mails as possible

I propose the following scheme:

1. The first time an issue is referred to the TC, a new bug will be
   created which is filed against `debian-ctte'.  This bug will
   be set to block all the other bug(s) involved.

    1a. If an existing bug is reassigned to the TC, or other
        irregularities occur, before discussion starts the first
        person to reply in the context of the TC will ensure that this
        situation is rectified.  This might involve creating the new
        bug and reassigning blocked bugs back to their originating

    1b. For avoidance of doubt, only bugs originally filed against the
        TC will be used for this purpose.

    1c. If multiple such bugs are created they will be merged but we
        will use only the lowest-numbered for discussion.

2. The specially-created bug will be used for all discussion.  All
   discussion will be CC'd to it.

3. Interested parties should subscribe to the bug when they become
   aware of the situation (for example by being alerted to it by a CC)
   and may have to read the archives of the TC bug to catch up.

4. Messages about a TC issue should NOT also be CC'd to the
   debian-ctte list.  (Since the BTS will send the messages there.)

5. Ideally messages should not be CC'd to
     - TC members
     - People participating in the discussion who have
       subscribed to the bug
   BUT the exact set of people included in that scope is not 100%
   clear and it is better to err on the side of including people:
     - Participants /should/ CC other people in the discussion
       unless they are sure that they're TC members or subscribed
       to the bug

6. When the discussion is completed and a decision made or the issue
   resolved, the TC bug will be closed but remain available for any
   further discussion, enforcement, or whatever.  The other bugs
   involved will naturally become unblocked and may need to be
   assigned or reassigned as appropriate.

    6a. The special TC discussion bug will not be reassigned to
        another package.

    6b. If necessary new bugs might be created, if none already
        exist, to ensure that every package which needs to change
        or team which needs to do work, has the appropriate

We should consider this proposal before implementing it, although of
course the current approach is very ad-hoc.


Reply to: