Fwd: REST APIs, and Tags

[Frédéric Buclin]

Le 11. 02. 10 19:26, Benjamin Smedberg a écrit :
> right now I think we categorize a lot of bugs which simply then get
> stored and ignored.

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.


> bugs. The primary use of bugzilla is a communication tool.

Right, but you seem to intentionally ignore some communication channels,
see above.


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


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

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.


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

Well, if that's what your triage teams are doing, then the failure is at
this level, not at the Bugzilla level. Simply ignore metadata you don't
care about. I don't understand your will to set data you don't care
about. Just ignore them and focus on what is important to fix the bug!


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

Either the module owner watches incoming bugs, or triagers CC them.


 The only cases in which we actively make bug
> decisions currently is when we are triaging bugs which are nominated to
> block some release.

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.


> 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

IMO, an additional bug status doesn't fix anything. You move the problem
from UNCO/NEW to NEW/READY.


> I believe that the problem of required metadata

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

> plugins and tabs in Mozilla/Firefox. I need the ability to categorize
> and organize bugs which are relevant to this effort.

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?


> * to allow interested QAfolk/developers to nominate bugs

We use the status whiteboard for that, in combination with CC'ing the
module owner who can take the decision.


> * to allow me to classify a set of bugs according to how serious they
> are and which milestone they should be fixed in

Severity + target milestone fields.


LpSolit