Re: Bug/Issue Tracking: Does it have politics?
On Fri, Feb 06, 2004 at 05:27:39PM -0500, Joseph Reagle wrote:
>
> http://reagle.org/joseph/blog/culture/bug-tracking
>
> I've noted that a common source of disagreement and even exit within open
> source communities is the handling of software bugs. In my experiences in
> the open standards communities the ways in which issues are represented
> with respect to their standing of consensus or dissension is affected by
> the processes, culture, and media of discourse (e.g. bugzilla, IRC, e-mail,
> Wiki, etc.).
Debian use debbugs, the Debian bug tracking system [0], which is a
completly open system (no registration/authentification is required to
perform any actions). It is mostly based on email. Prevention of abuse
are done by peer review (you cannot do anything without several people
being notified) in the similar way open Wikis do.
> Consequently, I'm interested in the extent to which communications media,
> issue tracking and bug tracking software reflect cultural values of how a
> community should come to agreement, or even to productively disagree. For
> example, culturally, can a developer close a bug report simply because he
> does not think it is of a priority? Technically, does the software permit
> the developer to specify an appropriate status for an issue, or reassign it
> to a more appropriate owner?
Debbugs permit anyone able to send an email to close, reassign a bug to
another package, change the severity, the submitter adress, the
categorisation, the title, and comment on the bug.
Note that bugs are assigned to packages and not to individuals, though
the package maintainer(s) is normally responsible for handling it.
Policy about the way the Debian BTS should be handled is described in
the Developers' Reference [1].
The current policy mandate that only the maintainers and the submitter
should close the bug. Other people should categorize it as 'fixed'
instead. This include bugs fixed by an upload of an updated package
by a developer who is not the maintainer (known as non-maintainer upload
(NMU)).
Bug severities are also defined. The three highest severities are
'release critical' which mean they prevent the package to be part
of the next stable release unless they are fixed. The lowest
severity is used for wishlist items.
Symbolic 'tags' are used as a way to categorize bugs. A bugs can have
several tags. A tag can denote the status or the scope of a bugs.
> Can you point me to examples of disputes arising over the categorization or
> responsibility of bugs? The implementation of new tools, categories, or
> processes that are hoped to mitigate such problems? If so, please let me
> know!
It has happened at some occasion that some bugs deserving a high
severity according to the Developers references was not to be treated as
release critical. This lead to a disagreement whether the severity
needed to be changed to reflect the status. To solve the problem, new
tags were added to denote the the 'non release critical' status of a bug
with a serious severity. For example a tag denote that a bug affect only
an older release.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
[0] http://bugs.debian.org
[1] http://www.debian.org/doc/developers-reference/
Reply to: