Fwd: REST APIs, and Tags

[Gervase Markham]

On 12/02/10 14:52, Benjamin Smedberg wrote:
> As a module owner who tries to respond and react to incoming bug
> reports, I don't disagree that there are ways to track incoming bugs. I
> do think that it would be good to put some energy into making the triage
> process easier and more explicit for those people who are tasked with
> doing it. That may involve going back to the old way of assigning bugs
> to particular people when they are filed, instead of nobody at mozilla.org.
> Those people will probably want a way to separate out bugmail from "bugs
> which are assigned to me in order to get an initial response" and "bugs
> assigned to me because I'm actually fixing them".

I think this is what Jesse's "Getting Bugs Done" proposal was trying to
achieve - have a person responsible for each step in the process, who is
the assignee at that particular point. The trouble was that defining all
that stuff in the workflow would have been loads of work in itself.

> The hardest part by far is selecting a component in which to file the
> bug. We have this built-in tension: having lots of little components is
> good for core developers, because they can watch "specialty" components
> without getting overloaded with email. Having a few large components is
> better for almost everyone else. I'd be interested to see if we could
> figure out a way to find the best of both worlds... perhaps hierarchical
> components so that all our layout/content/javascript bugs go in a "Web
> content" category, with subcategories for layout/content/javascript and
> sub-sub-categories for "layout: tables" or "content: XMLHttpRequest" or
> "javascript: JIT"... I don't know the right answer to this problem!

When Bugzilla needed a third level of categorization, we ended up adding
one at the top (Classifications) instead of at the bottom. This had
implementation advantages, but it does exacerbate this problem.

One option might be to have a set of triage components rather than just
one per product. So you could have Firefox/Web Content (Triage),
Firefox/User Interface (Triage) and so on. The bug filing UI would
direct bugs into there, and appropriate area owners would farm them out.

> At the end of this process is it clear to the original filer what has
> happened? I think many people see the flag changes, don't see any
> substantive comments, and still feel frustrated because they don't know
> (at least in mozilla... perhaps the bugzilla project is clearer!)

We could perhaps try and change this by encouraging people to comment
when triaging. Ubuntu has various bits of comment boilerplate for this;
it seems impersonal, but perhaps it's better than nothing.

> No, it's not because we "watch" those flags: it's because we have made a
> commitment to actually setting the flag to plus or minus before release.
> I would like a way to do that for every bug... it's almost as if every
> bug starts out with a triage?initial flag,

UNCONFIRMED?

> and after it's gone through
> the process it ends up as triage-done, 

READY?

> perhaps with trips through
> triage-ready or triage-needtestcase or whatever. Which is perhaps what
> we should do! I don't know yet.

We can add more states, or we can use NEW + "testcasewanted" keyword/tag.

> And the TM field feels useless because it doesn't have any of the
> "lorentz submilestones" in it, and people don't want to have a TM field
> with 150 entries for each subproject that might want to track things.

Currently TMs are per-product as a way to try and manage this
complexity. And still, the complexity rears its head - on the main
search page, and even in the current lists for each product which are
very long.

This is where using tags would make things simpler.

Gerv

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