Fwd: REST APIs, and Tags

[Benjamin Smedberg]

On 2/11/10 2:01 PM, Frédéric Buclin wrote:

> You can have the best UI you want, bugs you don't care about will
> *always* be ignored. As discussed in mozilla.dev.planning and in bug
> 545284, you can already track incoming bugs. You can also use saved
> searches as Atom feeds to track incoming bugs. So you have all you need
> to track newcomers.

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

We certainly don't have the resources to *fix* every bug that comes in. But 
I think one of our goals in the next bit is to find a way to respond to 
every bug that comes in and make its current state clear. In many cases that 
may be "this is a bug, but it's not important enough for the mozilla 
developer community to fix it".

>> 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
>
> As said in mozilla.dev.planning, new users have the guided form to
> report bugs, or the normal form with advanced fields hidden by default.
> I don't see what's hard here.

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!

> The perception of being a black hole is because people tend to ignore
> what comes into Firefox:General and Core:General. What prevents all
> module owners to watch the QA contact of *:General for new bugs only
> (you know how to do this), and pay attention to bugs which seem to
> belong to your modules? On one side, you complain about getting too much
> bugmail, and on the other one, you complain to not get enough bugmail,
> making you miss some bugs.

Yes, most of us currently ignore Firefox:General and Core:General. We're 
trying to fix that without destroying everyone's productivity. It may 
involve finding or paying people to help out. The question is though, what 
should these people do? Simply moving the bug to the correct component may 
not be enough: it would be better to explicitly hand it off to a module 
owner at some point who can then decide the priority, comment in the bug, 
and assign it to somebody/nobody depending on how important it is.

> I will give you an example, keeping in mind that Bugzilla (the project)
> is by far not as large as Firefox: when a new bug is reported, a quick
> look at it lets us pretty easily say if the bug seems severe, a possible
> dupe, a RFE, etc... We quickly set some fields and it should then be in
> everyone's radar who is interested by such or such bugs.

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!)

> That's because you watch flags having "blocking?". If you weren't
> watching them, you would miss them too. So watch what you need to watch.
> If you need help to have a working saved search to track incoming bugs,
> just tell; we can help here. And once it's built, you can even share it
> with other members of your team.

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, and after it's gone through the 
process it ends up as triage-done, perhaps with trips through triage-ready 
or triage-needtestcase or whatever. Which is perhaps what we should do! I 
don't know yet.

This makes it possible for module owners (or at least the ones who care!) to 
have simple queries for "all the bugs in my module which haven't been 
triaged yet".

> We don't *require* metadata, besides the component. You can ignore the
> OS/Platform fields if they are unimportant to you. Why again do you pay
> attention to them if they are meaningless for your team??

Because they are there, and especially because they confuse new users who 
try to use those fields in the advanced bug search form.

> Use the priority field. Use the target milestone field. Mark them as
> blocking some meta bug. And be sure they are in the correct component.
> What else cannot you do with that?

I cannot accept nominations for 'this might be important, please decide 
whether it blocks alpha1/beta1/final'. I cannot easily create a bug search 
of "everything which directly or indirectly blocks bug 478976 and is 
assigned to nobody@". (I think... I could be wrong, the advanced bug search 
form is sometimes beyond my understanding.)

The problem with the priority field is that it means different things to 
different people. At various times we have used it for:

* each developer prioritizes their own bug list
* priorities are per-component
* priorities plus blocking flags used as a poor-man's multi-state flag

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.

And FWIW, the correct component for these bugs is many different things, 
because this is a multi-disciplinary project!

In any case, I probably *could* solve this with status whiteboard 
pseudo-tags. My problem is that these combinations of existing 
flags/keywords would end up with special meaning that was clear to me and to 
a few other core developers, but is completely unclear to most people. It 
feels like  trying to work around limitations in the tool, and my goal was 
to propose extensions to the tool that would help me solve my problems in a 
less haphazard way, and hopefully in a way that was clearer to outside 
participants.

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