Fwd: REST APIs, and Tags

[Max Kanat-Alexander]

On 02/11/2010 10:26 AM, Benjamin Smedberg wrote:
> 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.

	Oh, that's an interesting thought. (Not that we haven't been doing
that, just that it's an interesting thing to think about the purpose
that way.)

> [snip] filing a bug is itself a
> painful activity, and seeing bugs stored-and-ignored is disheartening.

	The problem statement is good, but those are two separate problems that
probably have separate solutions.

	Also, by the way, if you stopped presenting new users with the Bugzilla
Helper and just used the default Simple Form in Bugzilla 3.4, I suspect
that filing a bug would become a far less painful experience.

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

	Okay, as far as filing bugs goes, I think the current problem is more
that there are too many bugs filed, not that there aren't enough people
filing bugs. So the black hole problem is probably more significant.

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

	That sounds pretty reasonable. :-)

> 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 should fix it.

	Yeah, that's actually what I've thought about the situation, myself,
for years.

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

	Yeah, I agree. I believe my most last suggestion in this area was that
Mozilla should hire several full-time bug triagers.

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

	Hmm. I do agree that there are a lot of cases where certain data just
isn't very important, particularly Platform/OS. Translating those into
tags might be reasonable, but I worry that then we'd shift the burden of
setting them properly *entirely* onto developers instead of how it is
now, where it's just *mostly* on developers (or the fields are ignored).

> PROBLEM STATEMENT B:
> 
> Advanced users and project leads need to be able to organize bugs
> better. [snip]

	Agreed.

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

	Hmm....

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

	Okay, I see this a little better now.

	A simple solution that would retain the current UI might be to only add
one of those "multi-state flags" (which are a hack on custom fields
that's specific to bmo) if they are somehow specifically set by the user
(so, say, a link like "add a flag" that pops up a <select> that lets you
choose a flag to add).

	It's also possible that bmo could use a Bugzilla Extension or some
external system for Project Management.

	By the way, thanks for these excellent problem statements, they're
really good.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.