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
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
