Fwd: REST APIs, and Tags

[Benjamin Smedberg]

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.

THEORY:

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.

SOLUTION?:

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 
bugzilla.

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.

PROPOSED SOLUTION:

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.

--BDS
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla