Fwd: REST APIs, and Tags
benjamin at smedbergs.us
Thu Feb 11 18:26:45 UTC 2010
On 2/11/10 11:08 AM, Max Kanat-Alexander wrote:
> The purpose of a bug tracker is, basically, to help people store and
> organize bug reports.
Actually, I think this is a problematic purpose statement. The purpose of
the bug tracker is to make it possible/easier to fix the incoming reports.
Some organization will help the overall goal of getting bugs fixed, but
right now I think we categorize a lot of bugs which simply then get stored
and ignored. In some cases I think we'd be better off with less
classification/organization of bugs and better *communication* of the bugs.
The primary use of bugzilla is a communication tool.
> #1 I usually like to think of as being phrased as a particular problem.
> The more overarching (but specific) the problem's statement, usually the
> better we can look at how to fix it. If it's too general or too
> nitpicky, then we just get into the details instead of the architecture.
OK, I'll attempt! Note that this is primarily about bugzilla.mozilla.org.
PROBLEM STATEMENT A:
bugzilla.mozilla.org currently works acceptably well if you are an everyday
user who is completely hooked into the project. But if you are an occasional
user, or new to the project, filing a bug is itself a painful activity, and
seeing bugs stored-and-ignored is disheartening. I believe that many web
developers and other skilled people who could aid the project are being
driven away by the difficulty of filing bugs and the perception (and
possible reality) that our bug tracker is a black hole.
The goal of this process should be to 1) give the bug enough details so that
it can be fixed 2) communicate to developers and the bug reporter how
important the bug is and when it might be fixed.
I believe that problem is partly caused by this: when we get an incoming bug
report, the primary goal of triage seems to be to get all the bug metadata
"correct". We make sure it has the right
Product/Component/OS/hardware/version. We add keywords, sometimes many
keywords. In the well-done cases we make sure there are good steps to
reproduce, or even a testcase.
All this activity masks the real problem, which is having some qualified
module owner/peer/delegate decide how important the bug is and whether/who
shold fix it. The only cases in which we actively make bug decisions
currently is when we are triaging bugs which are nominated to block some
release. This means that new bugs which are filed without blocking
nominations (the default situation most filers) are simply ignored.
For now I'll mostly omit proposed solutions: gerv and mconnor have proposed
various solutions for READY states and bug workflow which I think are partly
heading in the right direction, but I think that imposing additional
"process" without fixing the "communication problem" won't actually improve
I believe that the problem of required metadata can and should be solved
with keywords/tags/labels/whateveryoucall it. Most of the time the data
isn't important and we shouldn't bother with it. When it is important,
optional labels are going to have much better accuracy.
PROBLEM STATEMENT B:
Advanced users and project leads need to be able to organize bugs better. I
am leading the "Electrolysis" project to do multi-process plugins and tabs
in Mozilla/Firefox. I need the ability to categorize and organize bugs which
are relevant to this effort. I have tried various solutions, including a
wiki page external to bugzilla and tracking bugs with dependencies.
My requirements are:
* to allow interested QAfolk/developers to nominate bugs
* to allow me to classify a set of bugs according to how serious they are
and which milestone they should be fixed in
This problem is basically solved by multi-state flags, except that it's not
just me: the accessibility team, the JS team, etc are all running similar
projects and would like project-specific classifications. Having 30
multi-state flags down the right side of the bugzilla UI doesn't scale.
Project-specific labels which autocomplete for the various projects and have
configuration values as google code does. I don't particularly care whether
they use the existing multi-state flag backend data storage system... this
is mainly a question of UI.
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
More information about the developers