Tracker usage guidelines

From Web Real-Time Communications Working Group Wiki
Revision as of 16:23, 16 April 2012 by Halvestr (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Tracker Usage Guidelines

This is a Work In Progress, and is floated as input for the group.

Background

The group has two issue tracking systems:

  • Tracker is used to track actions within the group. We're only using the ACTION section.
  • Buganizer is available for tracking issues and bugs.

The Tracker is a tool integrated with the W3C mailing list and IRC tools; it updates issues based on mail that contains key phrases like ACTION-NN, and is able to create, update or close issues based on IRC commands.

The Buganizer is an ordinary ticket system, which sends mail to the mailing list for each bug update.

The use of Buganizer was discussed in a telechat on December 15.

Operational procedures, Tracker

We only use the action section of the tracker, not the issues section.

The Chairs use the Tracker to remember who has promised to do something - that might be a document update, contacting someone to ask about something, scheduling a meeting, running an errand ... anything that is a concrete, specific action.

When the action is reported as done, the tracker item is closed. When there are follow-on actions (for instance, when a question was asked and the WG needs to discuss the answer), a new action is raised; we don't change the old action.

The chairs have the ultimate decision power on when items are opened and closed. People assigned an item may close it when they think they have completed the item; if they report it to the list, they MUST include the words "action-NN" in the body of their mail; if they do not report it to the list, they SHOULD inform the chairs.

Operational procedures, Buganizer

The Buganizer is used when people discover problems in the spec. This may be badly worded phrases, non-functional links, procedures that are questionable, or missing functionality. A bug should contain at least:

  • A reference to the document it concerns, with document date and section title if possible.
  • A description of what the issue is about.
  • A statement of what the reporter thinks the state is (for example "obvious bug, fix it" or "I think this should be done differently, we need a discussion before deciding").

People can raise bugs by sending mail to the mailing list or to the WG chairs; the chairs or their designates will enter the bugs when appropriate.

Comments on the bug should, as far as possible, include a proposed fix, or words that indicate what an acceptable fix would be. Discussion of higher level topics are NOT appropriate for the bugtracker.

The chairs are responsible for assigning a responsible person to all bugs, and may reassign a bug when needed.

The responsible person is in charge of making sure the bug is discussed to the point where it is clear what to do (which may be "no change", or "change things this way"). When the bug is in a state where it's clear what should be done, and the result is "change", the responsible person will assign it to a document editor; if not, he/she will close the bug.

The editor will close the bug when the editor thinks that an editor's draft has been published that contains the fix.

If people find bugs that they think is solved, they can close them.