<scarabeus> remi`: 1) write all this down 2) put it on bugzie and assign it to idl0r and cc me and robin So here's a few things which I think could improve bugzilla, both for us as wranglers and devs, and for users. Theme ===== - Smaller fonts (not much) and less padding in the bug list. Searching ========= - Make the search field in the front page bigger - s/some search terms/application name/ - Add links at the top and bottom of the bug list to - suggest a better search term "firefox" -> "mozilla-firefox" (use eix for that?) - get the list of closed/duped bugs based on the current search list Filing new bugs (user mode) =========================== - Component list is useless (for instance Gnome herd gets a lot of bugs for packages that just happen to be using gtk+) - Drop Reproducability/Steps to reproduce/Actual Results/Expected Results entries (most users either don't know what to put or put useless junk in it) - Add a mandatory "emerge --info" field - Drop the severity field, again, most users pick wrong values for that field. Filing new bugs (expert mode) ============================= - Component list should have "Applications" or "Ebuilds" selected as a default value
Filing new bugs (user mode) =========================== - Version field seems useless. (at least for Product: Gentoo Linux) Filing new bugs (all modes) ============================= - Prevent double posts caused by refreshing. Bug-wrangling ============================= - Add a button / field that allows assigning and CCing people according to metadata.xml. This could be done by scanning the summary and picking the first thing that matches a package name. equery meta could give the needed info. All the emails to be added should be displayed near this button.
Filing new bugs (expert mode) ============================= - Make the status whiteboard fillable on the enter bug page. (Extensively used by Security)
Filing new bugs (user mode) =========================== - Template bugs for version bumps and stable requests. Add another step (on the page after selecting component: Gentoo Linux) asking: What do you want? * version bump * stable request * other The third would be the current template. The other two would be very minimal. Select a package, maybe add a version and an optional comment. One could even consider to automatically assigned those bugs to the maintainer.
Bug display =========== - Replace: * (CVE-\d{4}-\d{4}) with a link to http://web.nvd.nist.gov/view/vuln/detail?vulnId=$1 * GLSA (\d{6}-\d{2}) with a link to http://www.gentoo.org/security/en/glsa/glsa-$1.xml * SA(\d+) with a link to http://secunia.com/advisories/$1/
Filing new bugs (all modes) =========================== - Allow attaching files on submission. Filing new bugs (user mode) =========================== - Template bugs for new ebuilds and ebuild requests. This could be a more minimal template too, since most of the fields are irrelevant in this case. The user could be asked to propose a herd. This would save the bug-wrangler some time.
Searching ========= - Include the closed bugs of the last 1-3 days into the default search. This would save a lot duplicates (assuming the user searches for similar bugs with the default search only).
Wow, didn't expect so much new ideas on top of mine in such a short amount of time :D That's a pretty nice list we now have so far. Now we have to figure out : - what we want from the list - what's doable with what manpower - how disruptive the changes are wrt bugzilla software Side question : is there a "bugzilla project/team" or is this just a standard part of infra? Cheers
(In reply to comment #7) > Wow, didn't expect so much new ideas on top of mine in such a short amount of > time :D > Thanks for all your ideas! :) First priority has the migration itself, if that is done we will try to realize some/many ideas of this and other bugs, some of them _might_ be already implemented by upstream. For suggestions to bugzilla itself: Please read the feature list of bugzilla 3.x.x[1] (usually the most recent release) first to ensure it has not been implemented already, that makes it much easier if we're going to add new features. There are also some official demos[2] available which could be interesting as well. > That's a pretty nice list we now have so far. Now we have to figure out : > - what we want from the list > - what's doable with what manpower > - how disruptive the changes are wrt bugzilla software > How about if we make a small website with voting system or something similar? > Side question : is there a "bugzilla project/team" or is this just a standard > part of infra? > At the moment its more part of infra. [1] http://www.bugzilla.org/features/ [2] http://landfill.bugzilla.org/
(In reply to comment #8) > Thanks for all your ideas! :) > First priority has the migration itself, if that is done we will try to realize > some/many ideas of this and other bugs, some of them _might_ be already > implemented by upstream. I didn't know about the migration until after I wrote this :) > For suggestions to bugzilla itself: Please read the feature list of bugzilla > 3.x.x[1] (usually the most recent release) first to ensure it has not been > implemented already, that makes it much easier if we're going to add new > features. > There are also some official demos[2] available which could be interesting as > well. I'll definitely take a look. > How about if we make a small website with voting system or something similar? I'm not sure it's worth the trouble at this point, we should just try to see first among us if those things make sense. We can create polls if we ever hit a hard decision that we can't make. > At the moment its more part of infra. Alright, I'll join #-infra more often then :) Thanks
> Bug-wrangling > ============================= > - Add a button / field that allows assigning and CCing people > according to metadata.xml. This could be done by scanning the summary and > picking the first thing that matches a package name. equery meta could give > the needed info. All the emails to be added should be displayed near this > button. > I addition to that, it would be helpfull if there would be the possibility to select via dropdown/selectiondialog any valid foo@gentoo.org assigny.
(In reply to comment #10) > I addition to that, it would be helpfull if there would be the possibility to > select via dropdown/selectiondialog any valid foo@gentoo.org assigny. ~400 dev addresses plus all the aliases... That's probably too many for a single drop-down.
Filing new bugs (user mode) =========================== - Replace the Category list with a set of "I want to..." sentences for instance: "I want to report a security issue" "I want to request a new package to be added" "I have a problem with Bugzilla" "I have found a bug in the documentation" You get the picture. It might help to reduce the amount of bugs filed in the wrong category. (In reply to comment #7) > That's a pretty nice list we now have so far. Now we have to figure out : > - what's doable with what manpower I'll happily implement my ideas and others if needed. *blows the dust off his perl-fu* :)
Searching ========= - make quicksearch detect leading hash (#) as indicator of searching by bug id and ignore trailing dot in such search Rationale: relevant bug ids in ebuild changelogs are often indicated as '#bugid' or '#bugid.' so when you double click them the whole string is selected and pasting them into search box becomes not so smooth experience as you need to manually remove both leading and (often) trailing chars.
(In reply to comment #4) > * GLSA (\d{6}-\d{2}) with a link to > http://www.gentoo.org/security/en/glsa/glsa-$1.xml The whitespace is a problem if quoted and wrapped at that point.
I observed that responses on Gentoo bugzilla are not nice. Please don't get me wrong - they are *NOT* rude. For example I posted bug about problems building of glibc. As it was with new version of glibc I've searched for version, glibc etc. However the problem was with MAKEOPTS="V=1" which I haven't though of. I posted bug which turned out to be duplicate. Person marking the bug duplicate added comment that "I should have searched". The problem - I did search. The result - despite good intention I felt subconciously "attacked". I don't want to claim that person had any wrong intention (he wanted to inform me that I should have searched - which I should). Compare that with prepared response from gnome bugzilla: > Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. I find them a great help (even if particular response
(In reply to comment #15) > I observed that responses on Gentoo bugzilla are not nice. Please don't get me > wrong - they are *NOT* rude. > > For example I posted bug about problems building of glibc. As it was with new > version of glibc I've searched for version, glibc etc. However the problem was > with MAKEOPTS="V=1" which I haven't though of. > > I posted bug which turned out to be duplicate. Person marking the bug duplicate > added comment that "I should have searched". The problem - I did search. The > result - despite good intention I felt subconciously "attacked". I don't want > to claim that person had any wrong intention (he wanted to inform me that I > should have searched - which I should). > > Compare that with prepared response from gnome bugzilla: > > Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. > > I find them a great help (even if particular response > I'm really sorry - I prepared text off-line and just copy'n'past it when I found this bug. I wanted to proposed pre-prepared texts for Gentoo developers.
Hm, we need a clean list or so...
These suggestions are implemented or obsolete as far I can see. I suggest to create a wiki page for further suggestions (and open suggestions if there are any) and link it here. I suggest also to close the ticked as fixed.
