[darcs-users] http://wiki.darcs.net/DarcsWiki/BugTrackerIssueManagement (Was: Re: Petr Ročkai is the new darcs Release Manager)

[Eric Kow]

Hi,

Thanks for writing this.  This will be valuable for training the next issue
manager if for whatever reason you need to pass the torch.  Here are my
comments in case it helps. (BTW, the 'Raw Text' action on the wiki is quite
useful for commmenting on wiki posts via e-mail).  It may be worth deleting
the bits of http://wiki.darcs.net/DarcsWiki/BugTracker that you feel are
answered or maybe merging the two documents.  Or maybe it's good to have the
two separate documents, one for anybody who wants to help out, and one
specifically for the Issue Manager.

On Thu, Dec 11, 2008 at 15:20:37 +0100, Thorkil Naur wrote:
> In preparation for this, I have produced 
> http://wiki.darcs.net/DarcsWiki/BugTrackerIssueManagement with a description 
> of my current ideas for managing issues on the bug tracker. Comments from you 
> or other darcs users are most welcome.

Thorkil Naur wrote on the wiki:

= Bug Tracker Issue Management =

> The basic desire is to ensure that all issues move toward some sort of stable
> state, reflecting that issues that are raised get suitable attention and are
> resolved.

I'm just highlighting this to show darcs-users why we think this sort of thing
needs thought

== Bug Tracker Status Values ==

> At the time of writing this (2008-December-11), the bug tracker allows the
> following additional status values to be used:
> 
>  * {{{testing}}}
>  * {{{resolved-in-unstable}}}
>  * {{{resolved-in-stable}}}

Do you wish for me or Simon to take any action here, notably removing these
three status values?

== Bug Tracker Priority Values ==

> || {{{silly wishlist}}} || Not used ||

I get the impression that this was created during some bug tracker
experimentation and should be removed.

== Bug Tracker Keyword/Topic Values ==

> The use of keywords/topics is not covered by any particular rules, so new
> keywords/topics can be defined and used as one sees practical. However, it is
> important that all the keywords/topics are suitably described on
> BugTrackerKeywordTopicValues to make their intended use clear.

http://wiki.darcs.net/DarcsWiki/BugTrackerKeywordTopicValues for the interested
 
== Bug Tracker Issue Management Tasks ==

=== Which issues are triaged? ===

> This question is raised on BugTracker. The scheme described above intends to
> define clearly how an issue moves forward in status and that seems to be the
> main concern. Whether an issue can be said to be triaged seems to be of
> secondary importance.

Well, I think of 'triaged' as the first step in how an issue moves forward in
status, which is why I think it's useful to define this

> Clearly, the issues in the group that needs initial
> response and discussion are those that need most urgent attention, so it may
> make sense to say that all the remaining issues (in particular those with
> {{{need-info}}} and {{{need-volunteer}}} status) are the triaged ones and
> consider the issues with {{{unread}}} or {{{chatting}}} status as un-triaged.
> But one should keep in mind that issues can revert to the {{{chatting}}} status
> and hence would become un-triaged in this view.

I think it's perfectly acceptable to say that bugs can revert to being
un-triaged, in which 'un-triaged' is a blanket term for issues which are in a
'huh' state (without any clearly defined action or need-info, etc).

I would also consider the no-priority-set issues as untriaged, for the simple
reason that our issue tracker is currently configured to present them at the
very top of the front page (which seems to be a useful behaviour), and that we
should get them out of the way if we already know what to do with them.  The
reason I think this is important is because we want to make it easy for more
darcs hackers to use the issue tracker, and to avoid distracting them with
spurious front-page issues (i.e. things being on the front page without their
front-page-ness reflecting something like "look at me first"-ness).
Interestingly, people sometimes set the priority on the issues themselves, so
while I think it is necessary for the priority to be set, for us to consider an
issue as triaged, it is not sufficient.

Now for those of you aside from Thorkil who've been following this far (and
wondering what the fuss is about), basically we're just trying to work out a
reproducible, communicable and effective way of using the issue tracker.  The
reason we turn our attention to such minutae is because we want to turn bug
tracker usage into something a little bit more rigid, a little bit more
mechanical in the hopes of getting something more informative out of it.  My
two cents anyway :-)

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20081219/b5912cfb/attachment.pgp