Over the next few months, I will be working on improving bugzilla.mozilla.org to better meet the needs of the Mozilla development community.[0] I am therefore gathering 'requirements' - that is to say, asking people's opinion about which possible improvements would be most useful. This newsgroup post and an associated blogpost pointing here are a start; please let me know if there are other forums I could usefully ask in.
(I apologise if the reasonably wide crossposting irritates anyone. It seems that mozilla.announce has morphed into something which non-community-members subscribe to for notification about updates to Firefox and Thunderbird, so I suspect it's no longer appropriate for this sort of message. Perhaps we need a mozilla.dev.announce.)
Please say what the change you are requesting is, and why making it would improve your life. References to previous discussions and bug numbers would help.
Feel free to suggest configuration changes as well as code changes, of sizes both big and small. I anticipate working on maybe 1 or 2 larger things, but I hope to also be able to fix some small-but-annoying things along the way. I can't promise that any particular change will be worked on, even if supported very vocally. There are a number of factors which will affect the decision, including our desire to help the Bugzilla development community achieve its goals - both technical and social.
I can't promise a timeframe by which the changes will be available. My aim is, for non-b.m.o.-specific changes, to get them into the Bugzilla trunk and have them flow down to b.m.o. from there. And so it is dependent on Bugzilla release schedules and b.m.o. upgrades, which are themselves dependent on our release cycles and on IT time.
My pet would be a truly-JSON API to get data out of bugzilla. Our use case is the l10n dashboard, which we'd like to have bugilla integrated with. I'll probably need to get to my drawing board to give some concrete queries we'd want. Here having aggregated data is a big win, too. 75 queries to bugzilla suck, where we'd really want something like "number of open bugs per component in l10n" or "number of open blockers of bugs with an alias matching 'fx35-l10n-.*'"
A smaller thing would be to support filling in the alias via the URL. I have forms that generate those urls from data, so having the alias makes sense (more than in the case of static links). This is bug 310532. When filing the flock of bugs for new locales, getting the alias right is manual work each time.
I guess that finding out a better way to have "fixed here, but needs fixing somewhere else" would be cool, and support for that in queries.
Shorter query urls by default, maybe.
Better caching? Not sure, but I think we reload a lot these days.
> My pet would be a truly-JSON API to get data out of bugzilla. Our use > case is the l10n dashboard, which we'd like to have bugilla integrated > with. I'll probably need to get to my drawing board to give some > concrete queries we'd want. Here having aggregated data is a big win, > too. 75 queries to bugzilla suck, where we'd really want something like > "number of open bugs per component in l10n" or "number of open blockers > of bugs with an alias matching 'fx35-l10n-.*'"
Along these lines, being able to pull the chart data out through JSON or even anything that didn't require you to be logged in would make it easier to do nicer graphs than bugzilla can handle.
> Please say what the change you are requesting is, and why making it > would improve your life. References to previous discussions and bug > numbers would help.
Bug 209181 will save lots time when processing lot bugs and you need to know if reporter mail not bounced.
> My pet would be a truly-JSON API to get data out of bugzilla. Our use > case is the l10n dashboard, which we'd like to have bugilla integrated > with.
Is it good enough to have the JSON API have the same capabilities as the current query page, or do you need more?
> too. 75 queries to bugzilla suck, where we'd really want something like > "number of open bugs per component in l10n" or "number of open blockers > of bugs with an alias matching 'fx35-l10n-.*'"
One additional thing I'll guess you need is an option to return a count rather than the bug data?
> A smaller thing would be to support filling in the alias via the URL.
I have no idea why this doesn't work at the moment. I can see why people object to it being part of the bookmarkable template (it makes it much more likely for submitting the template to throw an error) but I have no idea why &alias=foo on the URL doesn't work. This just seems like a bug.
> Along these lines, being able to pull the chart data out through JSON or > even anything that didn't require you to be logged in would make it > easier to do nicer graphs than bugzilla can handle.
I think we required a login to view charts because otherwise it makes it very easy to DOS Bugzilla. But we could re-examine that decision.
> I can't promise a timeframe by which the changes will be available. My > aim is, for non-b.m.o.-specific changes, to get them into the Bugzilla > trunk and have them flow down to b.m.o. from there. And so it is > dependent on Bugzilla release schedules and b.m.o. upgrades, which are > themselves dependent on our release cycles and on IT time.
Given that you will be doing things the right way with all the latency that implies, I think the best thing is to focus on making bugzilla something that people can easily experiment with and hack on.
As Axel suggests, I think this translates into making as much as possible have a JSON API, and then having some documentation and examples. Right now you can do/get a lot using XML (and some via JS), but because of cross-site restrictions[1], this leaves you needing to either operate with chrome privileges or have your server do a mod_proxy trick.
While I think there are serious workflow issues in bugzilla that need to be dealt with, I think it's a better idea to be able to prototype workflow solutions and use them than to have to develop them in comparative isolation and have to go through a release cycle to be able to see the results. Things that require new fields or other constructs in bugzilla could be 'worked around' in prototypes by using a CouchDB instance to store the meta-data, for example.
From what I can see, bugzilla is already pretty close to having a usable remote API, so it seems like a beneficial initial strategy...
Andrew
1: Grepping bugzilla trunk, I saw no mention of the Access-Control-Allow-Origin header that would allow cross-site XHR in FF 3.5, and a quick check against bmo using "wget --server-response" did not show the header being introduced by the server either. Just having the server enable the header is probably a very wrong thing because of the potential horrible cross-site hacks.
Gervase Markham wrote: > Over the next few months, I will be working on improving > bugzilla.mozilla.org to better meet the needs of the Mozilla development > community.[0] I am therefore gathering 'requirements' - that is to say, ... > Please say what the change you are requesting is, and why making it > would improve your life. References to previous discussions and bug > numbers would help.
1. Support for user-id auto-complete or lookup in the CC field. It seems that lots of folks use a different email address in bugzilla than they do in email or newsgroups. If you try to CC the other address, bugzilla rejects the post because the email address is unknown to it.
2. Support for figuring out which build a FIXED bug shows up in. Notifications when the first such build is available. Firebug gets a bug report that we track down to mozilla, then we add a bugzilla report. Then we watch dozens of emails over months as the fix moves forward. Then the bug is marked FIXED and we are left in limbo. We can't tell our users to try it and yet we won't get another prompt about the problem. Our users think we left it on the floor.
Barton<johnjbar...@johnjbarton.com> wrote: > 2. Support for figuring out which build a FIXED bug shows up in. > Notifications when the first such build is available. Firebug gets a bug > report that we track down to mozilla, then we add a bugzilla report. Then we > watch dozens of emails over months as the fix moves forward. Then the bug is > marked FIXED and we are left in limbo. We can't tell our users to try it and > yet we won't get another prompt about the problem. Our users think we left > it on the floor.
FWIW, "the first such build" for FIXED bugs is always going to be "the next nightly from trunk", where you should presume those builds are taken from around 3AM Pacific.
Gervase Markham wrote: > Over the next few months, I will be working on improving > bugzilla.mozilla.org to better meet the needs of the Mozilla development > community.[0] I am therefore gathering 'requirements' - that is to say, ... > Please say what the change you are requesting is, and why making it > would improve your life. References to previous discussions and bug > numbers would help.
Remove all of the relative version number aspects of bugzilla, eg 'trunk'. Since some bugs live longer than the binding of 'trunk' to 1.9.1, the word is ambiguous and you always have to double check it.
Mike Shaver wrote: > On Fri, Jun 12, 2009 at 11:38 AM, John J. > Barton<johnjbar...@johnjbarton.com> wrote: >> 2. Support for figuring out which build a FIXED bug shows up in. >> Notifications when the first such build is available. Firebug gets a bug >> report that we track down to mozilla, then we add a bugzilla report. Then we >> watch dozens of emails over months as the fix moves forward. Then the bug is >> marked FIXED and we are left in limbo. We can't tell our users to try it and >> yet we won't get another prompt about the problem. Our users think we left >> it on the floor.
> FWIW, "the first such build" for FIXED bugs is always going to be "the > next nightly from trunk", where you should presume those builds are > taken from around 3AM Pacific.
Ok then for Grev's list:
A better UI for nightly builds that includes: 1) a naming convention in user terms ("Firefox 3.6 June 6 2009") 2) a date-last navigation tree (mozilla/firefox/3.6/date, not firefox/date-mozilla), 3) information about the unit-test status of the build, 4) a way to get notified about the next nightly build after a FIXED bug that will be usable. (Maybe it would fun to do this via social mechanisms, have nightly build instrumented to push "I came up!", "I ran and exited cleanly!", "I crashed badly :-(" to the nightly-build server.
> Gervase Markham wrote: >> Over the next few months, I will be working on improving >> bugzilla.mozilla.org to better meet the needs of the Mozilla >> development community.[0] I am therefore gathering 'requirements' - >> that is to say, > ... >> Please say what the change you are requesting is, and why making it >> would improve your life. References to previous discussions and bug >> numbers would help.
> Remove all of the relative version number aspects of bugzilla, eg > 'trunk'. Since some bugs live longer than the binding of 'trunk' to > 1.9.1, the word is ambiguous and you always have to double check it.
I'd just remove the version field, it mostly isn't used for anything useful.
Gervase Markham wrote: > I think we required a login to view charts because otherwise it makes it > very easy to DOS Bugzilla. But we could re-examine that decision.
I assume you're talking about the "new" charts? There's also privacy concerns because the charts could be answering questions about bugs in private groups.
> Please say what the change you are requesting is, and why making it > would improve your life. References to previous discussions and bug > numbers would help.
* Remove the Hardware and OS fields:
The Hardware/OS fields are constantly misunderstood or misused: bug-filers don't know whether they mean "I'm using windows" or "this bug is windows-specific", and this means that the data is inconsistent, which makes searching based on the OS/Hardware meaningless. Asking bug filers to fill in metadata that isn't actually required is an unnecessary burden.
* Remove the severity field
The "blocker" and "enhancement" severities actually mean something to us currently, but everything inbetween is basically "a bug of some sort" without much actionable difference. I think we should instead have a "blocking trunk" flag which we use to mark bugs which should close the mozilla-central tree, and an enhancement keyword to mark enhancement bugs.
* Combine Status and Resolution
Status and Resolution always come in pairs... it seems silly to have two fields where one would do quite well.
* Track FIXEDness per-branch
This is by far the hardest and most pie-in-the-sky request, but one which I think would be most valuable.
> Mike Shaver wrote: >> On Fri, Jun 12, 2009 at 11:38 AM, John J. >> Barton<johnjbar...@johnjbarton.com> wrote: >>> 2. Support for figuring out which build a FIXED bug shows up in. >>> Notifications when the first such build is available. Firebug gets a bug >>> report that we track down to mozilla, then we add a bugzilla report. Then >>> we >>> watch dozens of emails over months as the fix moves forward. Then the bug >>> is >>> marked FIXED and we are left in limbo. We can't tell our users to try it >>> and >>> yet we won't get another prompt about the problem. Our users think we >>> left >>> it on the floor.
>> FWIW, "the first such build" for FIXED bugs is always going to be "the >> next nightly from trunk", where you should presume those builds are >> taken from around 3AM Pacific.
> Ok then for Grev's list:
> A better UI for nightly builds that includes: > 1) a naming convention in user terms ("Firefox 3.6 June 6 2009") > 2) a date-last navigation tree (mozilla/firefox/3.6/date, not > firefox/date-mozilla), > 3) information about the unit-test status of the build, > 4) a way to get notified about the next nightly build after a FIXED > bug that will be usable. (Maybe it would fun to do this via social > mechanisms, have nightly build instrumented to push "I came up!", "I ran > and exited cleanly!", "I crashed badly :-(" to the nightly-build server.
> Over the next few months, I will be working on improving > bugzilla.mozilla.org to better meet the needs of the Mozilla development > community.[0] I am therefore gathering 'requirements'
I'd like to see improvements to the way reviews are handled. EG, suggesting appropriate reviewers (perhaps based on some combination of the bug's component, files in the patch, and reviewer queue length). Some concept of "next action" could also be useful here, I think Jesse had posted some ideas about that not too long ago.
I want "next action" and "next action assignee" fields (replacing several existing fields). Then each contributor will be able to find bugs they can help with, and fewer bugs will fall into the trap of being part of an unmanageable "pile of stuff".
Bernd, Chris Lawson, alanjstr, Frederic Wenzel, and Brendan Eich are all enthusiastically in support of this proposal.
> On Fri, Jun 12, 2009 at 11:38 AM, John J. > Barton<johnjbar...@johnjbarton.com> wrote: >> 2. Support for figuring out which build a FIXED bug shows up in. >> Notifications when the first such build is available. Firebug gets a bug >> report that we track down to mozilla, then we add a bugzilla report. Then we >> watch dozens of emails over months as the fix moves forward. Then the bug is >> marked FIXED and we are left in limbo. We can't tell our users to try it and >> yet we won't get another prompt about the problem. Our users think we left >> it on the floor.
> FWIW, "the first such build" for FIXED bugs is always going to be "the > next nightly from trunk", where you should presume those builds are > taken from around 3AM Pacific.
We have a somewhat odd problem in l10n, as we're usually fixing bugs on branch, and then port to trunk.
So, for new locales, we start working on the 1.9.1 branch, work towards resolving the bug FIXED there and then need to find a way to track if the bug is fixed on trunk, too.
I don't really recall what we came up with, I think I personally leaned towards a "fixed-1.9.2" keyword.
Justin Dolske <dol...@mozilla.com> wrote: > I'd like to see improvements to the way reviews are handled. EG, > suggesting appropriate reviewers (perhaps based on some combination of > the bug's component, files in the patch, and reviewer queue length). > Some concept of "next action" could also be useful here, I think Jesse > had posted some ideas about that not too long ago.
Related to this, it might be nice to be able to associate patches with hgweb revision pages or other ways to track which patches have landed on which branches. If we did that, it might also be useful to be able to link two patches as "patch for branch A and patch for branch B." -- Blake Kaplan
> The Hardware/OS fields are constantly misunderstood or misused: bug-filers > don't know whether they mean "I'm using windows" or "this bug is > windows-specific", and this means that the data is inconsistent, which makes > searching based on the OS/Hardware meaningless. Asking bug filers to fill in > metadata that isn't actually required is an unnecessary burden.
How then would you discover bugs that are OS dependent? I'm dealing with them every day, and it would awfully complicate my work if that field was not there.
As a compromise one could remove the OS and Hardware fields from the guided form. But then I am not sure how I could reliably search for all OS/2 bugs that were filed over the last 5 days...
> How then would you discover bugs that are OS dependent? I'm dealing > with them every day, and it would awfully complicate my work if that > field was not there.
> As a compromise one could remove the OS and Hardware fields from the > guided form. But then I am not sure how I could reliably search for > all OS/2 bugs that were filed over the last 5 days...
I think that specific search requirements can be better met with keywords, since most bugs are not platform-specific. I think the principle should be "don't have metadata fields where a keyword will work".
Great to hear that you are thinking about making some changes to bugzilla, I'm cc'ing Max and Guy since they have been in a lot bugzilla UI discussions with us recently as well.
Two of the previous suggestions that I think would significantly improve things are John's idea about CC autocomplete, and Jesse's idea of "next action.
For the autocomplete, it would be even better if we searched against full name and all associated email addresses on an account, and started by ranking results with a combination of:
- how active a user is on bugzilla - how commonly a user is cc'ed on the same bugs as the logged in user - the context of the specific product and component of the bug
And from that ranking start to bring in some quicksilver / Ed Lee / adaptive learning awesomesauce.
In terms of Jesse's "next action" idea, the reason I really want this is to be able to differentiate between bugs that are "uiwanted, but we are still working on implementation stuff" and "all work has stopped until the uiwanted keyword is removed." The "next action" field would of course clear that up significantly, and that's just one specific example, there are a lot of other cases where it would streamline our work.
Two new suggestions that I think would also be useful
1 - User Profile Pages. Not in the "turning bugzilla into a social network for dating" sense, but more being able to navigate on a particular user and found out how many bugs they have completed, how many they have filed, what components they generally work in, what time zone they are in (if they want to disclose it), what their irc nick is, etc. This could also be a place for people to display any Friends of the Tree badges they have earned, and the profile system could almost have a kind of a game design feel. Basically this is your bugzilla gamertag. Various actions on bugzilla could increase your gamerscore. Goals of the design could include: making bugzilla users feel like they are making progress and achieving things by using the system, improving our view which members of our community are extremely active and helpful, and overall helping to answer the common question of "who is [username]?" Note that I am not suggesting that people would be able to friend each other, only that people could become friends of particular bugs (we already support this :)
2 - API for accessing the same type of activity that is exposed through bugmail. I think reading plain text bugmail as an overall workflow each day isn't very well designed, and it is also something that many of us spend hours doing. I have a few ideas of how we could create various Web based interfaces that completely replace the need for individual bugmail messages, but the first step towards being able to experiment with new interfaces and workflows is getting access to the stream of data.
Cheers, -Alex
On Jun 12, 2009, at 8:38 AM, John J. Barton wrote:
> 1. Support for user-id auto-complete or lookup in the CC field. It > seems that lots of folks use a different email address in bugzilla > than they do in email or newsgroups. If you try to CC the other > address, bugzilla rejects the post because the email address is > unknown to it.
On Jun 12, 2009, at 11:03 AM, Jesse Ruderman wrote:
> I want "next action" and "next action assignee" fields (replacing > several existing fields). Then each contributor will be able to find > bugs they can help with, and fewer bugs will fall into the trap of > being part of an unmanageable "pile of stuff".
> Bernd, Chris Lawson, alanjstr, Frederic Wenzel, and Brendan Eich are > all enthusiastically in support of this proposal.
Andrew Sutherland wrote: > 1: Grepping bugzilla trunk, I saw no mention of the > Access-Control-Allow-Origin header that would allow cross-site XHR in FF > 3.5, and a quick check against bmo using "wget --server-response" did > not show the header being introduced by the server either. Just having > the server enable the header is probably a very wrong thing because of > the potential horrible cross-site hacks.
As long as it's only returning public data (i.e. XS-XHR without cookies) I don't see what would be wrong about enabling this. Would not help me in particular because I deal with a lot of bugs that are restricted to groups, but could be useful for a lot of other things.
Allowing bugzilla installations to specify "trusted servers" for more complete sharing could be useful and done safely, but I don't think it would be useful or safe for the BMO installation.
Gervase Markham wrote: > On 12/06/09 12:49, Axel Hecht wrote: >> My pet would be a truly-JSON API to get data out of bugzilla. Our use >> case is the l10n dashboard, which we'd like to have bugilla integrated >> with.
> Is it good enough to have the JSON API have the same capabilities as the > current query page, or do you need more?
Note that current queries support both XML and CSV output, and the query request can specify the columnlist you want for the output.
>> too. 75 queries to bugzilla suck, where we'd really want something like >> "number of open bugs per component in l10n" or "number of open blockers >> of bugs with an alias matching 'fx35-l10n-.*'"
> One additional thing I'll guess you need is an option to return a count > rather than the bug data?
you can get the count of a single query using ctype=microsummary, but if you wanted the number "per component" you have to write one query per component and run each of them separately.
What I think he wants (and if he doesn't I do) is support for GROUP BY. If we had this feature and it just generated a "group count" column then we could read the output using the currently supported output formats (plus JSON if you add a general JSON option).
|
