Hi,
I'm interested in what is the current "bug report management" going on with MediaWiki at the moment, and if it can be improved. Bugzilla is purported to be the method of communication between the Wikimedia project communities and the MW developers. But I find it fairly unsatisfying because I feel like when I file bug reports/feature requests, I have no confidence that they will even be read, let alone considered as a community request, responded to, placed in a roadmap or given a developer-POV priority. I feel like the only I can have any guarantee of the software feature I want being considered, is to befriend individual developers and try and convince them about my idea. Obviously, this doesn't scale well.
http://www.bobcongdon.net/blog/2005/11/triage.html Maybe it would help to try and encourage developers and techie types to do more (or any?) bug triaging, eventually leading to individuals or groups responsible for triaging all bugs entered within particular Product & Component values? Extension authors are obviously responsible for triaging their own extensions' bugs, but especially for the Wikimedia and MediaWiki products I think this should be helpful.
I couldn't find any mention of this kind of bug report management or bug triaging on mediawiki.org, so I am guessing whatever is done at the moment is fairly ad-hoc.
It is difficult to "see" activity on bugzilla, a la Recentchanges. (I guess if you are subscribed to wikibugs-l you see everything...) for example there is no straightforward way (ie link from the mainpage) to see the most recently entered bugs, or the most recently closed bugs, or the highest priority still-open bugs. These are probably fairly straightforward reports -- maybe it would be good to link them on the bugzilla front page?
If activity on bugzilla was more visible, it would be easier to thank people who spend time on bug triaging. (an otherwise extremely thankless task!)
Another idea would be to have regular bug triage days/events, like maybe one weekend a month, and just publicise them on here and mediawiki.org.
I guess I would also like to know more generally, what can Wikimedia communities do to communicate their tech priorities to y'all more clearly? What can we do better to get clearer feedback? (Even hearing a "no" at least gives one closure. :)) Is Bugzilla the best and only method? Is it helpful if a community appoints a 'tech request manager' who acts as a filter/gateway between the developers and the wiki community?
thanks, Brianna [[user:pfctdayelise]]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A few quick notes:
* I at least _see_ every bug, though during busy times (like conferences) I can get behind. I also don't necessarily comment on everything myself, so bugs that aren't getting attention may lack feedback. :(
* Things that don't get immediate attention often do end up not being touched again until either someone agitates or someone happens to find it and feel like fixing it themselves.
* I'd like us to get on a standard of ensuring that all bugs new / patches get some sort of comment within X days -- either a fix, a rejection, or an explanation why it's going on the back burner. This means getting some basic metrics in place, and some regular reporting of patches falling towards the long end of the limit.
* A few times I've experimented with "bug days" grabbing folks on IRC to find bugs of interest and either get patches made or existing patches reviewed and committed. They've been pretty good, but we haven't quite gotten to making them a regular thing yet. I'd definitely like to get that going again!
* As we have more "directable" resources (more people on staff or contracting), I'll start to have some more ability to specifically assign certain types of bugs to people... but it's always more fun when people take on bugs that interest them. :)
- -- brion
Brianna Laugher wrote:
Hi,
I'm interested in what is the current "bug report management" going on with MediaWiki at the moment, and if it can be improved. Bugzilla is purported to be the method of communication between the Wikimedia project communities and the MW developers. But I find it fairly unsatisfying because I feel like when I file bug reports/feature requests, I have no confidence that they will even be read, let alone considered as a community request, responded to, placed in a roadmap or given a developer-POV priority. I feel like the only I can have any guarantee of the software feature I want being considered, is to befriend individual developers and try and convince them about my idea. Obviously, this doesn't scale well.
http://www.bobcongdon.net/blog/2005/11/triage.html Maybe it would help to try and encourage developers and techie types to do more (or any?) bug triaging, eventually leading to individuals or groups responsible for triaging all bugs entered within particular Product & Component values? Extension authors are obviously responsible for triaging their own extensions' bugs, but especially for the Wikimedia and MediaWiki products I think this should be helpful.
I couldn't find any mention of this kind of bug report management or bug triaging on mediawiki.org, so I am guessing whatever is done at the moment is fairly ad-hoc.
It is difficult to "see" activity on bugzilla, a la Recentchanges. (I guess if you are subscribed to wikibugs-l you see everything...) for example there is no straightforward way (ie link from the mainpage) to see the most recently entered bugs, or the most recently closed bugs, or the highest priority still-open bugs. These are probably fairly straightforward reports -- maybe it would be good to link them on the bugzilla front page?
If activity on bugzilla was more visible, it would be easier to thank people who spend time on bug triaging. (an otherwise extremely thankless task!)
Another idea would be to have regular bug triage days/events, like maybe one weekend a month, and just publicise them on here and mediawiki.org.
I guess I would also like to know more generally, what can Wikimedia communities do to communicate their tech priorities to y'all more clearly? What can we do better to get clearer feedback? (Even hearing a "no" at least gives one closure. :)) Is Bugzilla the best and only method? Is it helpful if a community appoints a 'tech request manager' who acts as a filter/gateway between the developers and the wiki community?
thanks, Brianna [[user:pfctdayelise]]
On Mon, Aug 4, 2008 at 1:45 AM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A few quick notes:
- I at least _see_ every bug, though during busy times (like
conferences) I can get behind. I also don't necessarily comment on everything myself, so bugs that aren't getting attention may lack feedback. :(
I know I'm a volunteer, but I try to do the same. I check the buglist probably once every day or so for new showings. If it's something I either can help with or at least provide feedback on, I try to comment. No feedback at all is what makes things appear stagnant or makes the developers seem less accessible. Neither is the truth, really.
[snip]A lot of valid points[/snip]
- A few times I've experimented with "bug days" grabbing folks on IRC to
find bugs of interest and either get patches made or existing patches reviewed and committed. They've been pretty good, but we haven't quite gotten to making them a regular thing yet. I'd definitely like to get that going again!
Whoo! Monday bugfix day is always fun :-)
-Chad
From: "Brion Vibber" brion@wikimedia.org Sent: Monday, August 04, 2008 7:45 AM
- I at least _see_ every bug, though during busy times (like
conferences) I can get behind. I also don't necessarily comment on everything myself, so bugs that aren't getting attention may lack feedback. :(
- Things that don't get immediate attention often do end up not being
touched again until either someone agitates or someone happens to find it and feel like fixing it themselves.
Hello Brion,
what can I do to get a comment from you about bug 11555? I am just interested if this bug can be fixed or not. I don't want to become an agitator. An explanation would be nice. Sorry for repeating my question but I would like to get your attention.
More info: http://scriptingenabled.org/2008/07/the-biggest-barrier-to-accessibility-and... http://blind.wikia.com/wiki/Accessibility_and_Wikis#Section_title_and_edit_l...
^_^ If you have a list of potential "directable" resources, put me on there.
There are plenty of longstanding bug reports or features in bugzilla which I do have an interest in, and an idea on how to fix. I just can't get around to any of them, because those need a fair bit of focus, and right now I can only focus on something if it gives me a good portfolio item (MediaWiki extensions and code changes don't cut it in that area, I need a system with a UI that was discernibly made by me), or pays.
I honestly don't know about the Triaging of bugs. As I see it MediaWiki is quite more open and free form than other projects I see. We have few general groups of people who would be compelled to triage a large list of bugs. Rather people take a category of bugs they are good with (UI, Special pages, extension features, API, etc...) and they grab some they are interested in and fix them. The "release cycle" MediaWiki uses also differs a fair bit. We're not on a planned schedule of "these features are what we want to see by the next release", people just come up with improvements and add them into the software.
Though, perhaps a better way of visualizing the bugs we have would be good. We have some generic categories in bugzilla, but I don't see fine enough categories or tags which can help attract people to bugs on things they are interested in. Actually, the notion of trying to search bugzilla for 'features', or 'issues to fix' is a bit of a mess. What would be interesting would be a real 'feature tracker', rather then a mess of bugzilla reports, an actual categorized, and tagged list of features people would like to see in the software. Something with more control and organization than bug reports. Even a tag cloud with a variety of free-form categories would help to track down bugs/features one could work on.
((Perhaps sidetracking by now...)) Actually, COfundOS http://www.cofundos.org/ has an interesting concept. While I'm not a fan of the method there for selecting who would do something, it is an interesting concept. Especially if it were made more open and simply integrated with feature tracking, rather than focusing on the payment. * Put the features out in a list. * Comment on what the feature needs. * If people are highly interested in the outcome of a feature, they can throw in a buck or two. * Someone interested in working on the feature can claim it and start working. ** If someone else is interested they could claim as well. ** The claiming developers can discuss the task, see if they want to share the work, have one abdicate the claim and let the other work, or build and see who has the better outcome. * When the feature is completed the task is resolved, and if anyone chipped in for the feature it gets sent to the dev(s). It would work whether anyone chipped in for the feature or not. And if people did chip in, the dev would get some spare change as thanks for doing something they may have been interested in working on themselves. Wiki work breeds wiki? How many devs have their own hosting for running MediaWiki, even if it's only testing? https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=transwiki&product=MediaWiki&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com)
Brion Vibber wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A few quick notes:
- I at least _see_ every bug, though during busy times (like
conferences) I can get behind. I also don't necessarily comment on everything myself, so bugs that aren't getting attention may lack feedback. :(
- Things that don't get immediate attention often do end up not being
touched again until either someone agitates or someone happens to find it and feel like fixing it themselves.
- I'd like us to get on a standard of ensuring that all bugs new /
patches get some sort of comment within X days -- either a fix, a rejection, or an explanation why it's going on the back burner. This means getting some basic metrics in place, and some regular reporting of patches falling towards the long end of the limit.
- A few times I've experimented with "bug days" grabbing folks on IRC to
find bugs of interest and either get patches made or existing patches reviewed and committed. They've been pretty good, but we haven't quite gotten to making them a regular thing yet. I'd definitely like to get that going again!
- As we have more "directable" resources (more people on staff or
contracting), I'll start to have some more ability to specifically assign certain types of bugs to people... but it's always more fun when people take on bugs that interest them. :)
- -- brion
Brianna Laugher wrote:
Hi,
I'm interested in what is the current "bug report management" going on with MediaWiki at the moment, and if it can be improved. Bugzilla is purported to be the method of communication between the Wikimedia project communities and the MW developers. But I find it fairly unsatisfying because I feel like when I file bug reports/feature requests, I have no confidence that they will even be read, let alone considered as a community request, responded to, placed in a roadmap or given a developer-POV priority. I feel like the only I can have any guarantee of the software feature I want being considered, is to befriend individual developers and try and convince them about my idea. Obviously, this doesn't scale well.
http://www.bobcongdon.net/blog/2005/11/triage.html Maybe it would help to try and encourage developers and techie types to do more (or any?) bug triaging, eventually leading to individuals or groups responsible for triaging all bugs entered within particular Product & Component values? Extension authors are obviously responsible for triaging their own extensions' bugs, but especially for the Wikimedia and MediaWiki products I think this should be helpful.
I couldn't find any mention of this kind of bug report management or bug triaging on mediawiki.org, so I am guessing whatever is done at the moment is fairly ad-hoc.
It is difficult to "see" activity on bugzilla, a la Recentchanges. (I guess if you are subscribed to wikibugs-l you see everything...) for example there is no straightforward way (ie link from the mainpage) to see the most recently entered bugs, or the most recently closed bugs, or the highest priority still-open bugs. These are probably fairly straightforward reports -- maybe it would be good to link them on the bugzilla front page?
If activity on bugzilla was more visible, it would be easier to thank people who spend time on bug triaging. (an otherwise extremely thankless task!)
Another idea would be to have regular bug triage days/events, like maybe one weekend a month, and just publicise them on here and mediawiki.org.
I guess I would also like to know more generally, what can Wikimedia communities do to communicate their tech priorities to y'all more clearly? What can we do better to get clearer feedback? (Even hearing a "no" at least gives one closure. :)) Is Bugzilla the best and only method? Is it helpful if a community appoints a 'tech request manager' who acts as a filter/gateway between the developers and the wiki community?
thanks, Brianna [[user:pfctdayelise]]
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiWl4wACgkQwRnhpk1wk46/HQCgkT7VsOFChXNOJpwWTfhIQl/N RkcAn2WPtOZMEfvpBEJVi9ax0GEfrUmj =2W+4 -----END PGP SIGNATURE-----
On Mon, Aug 4, 2008 at 3:16 PM, Brianna Laugher brianna.laugher@gmail.com wrote:
It is difficult to "see" activity on bugzilla, a la Recentchanges. (I guess if you are subscribed to wikibugs-l you see everything...) for example there is no straightforward way (ie link from the mainpage) to see the most recently entered bugs, or the most recently closed bugs, or the highest priority still-open bugs. These are probably fairly straightforward reports -- maybe it would be good to link them on the bugzilla front page?
I've got a bugzilla RSS feed in the works.
Brianna Laugher wrote:
It is difficult to "see" activity on bugzilla, a la Recentchanges. (I guess if you are subscribed to wikibugs-l you see everything...) for example there is no straightforward way (ie link from the mainpage) to see the most recently entered bugs, or the most recently closed bugs, or the highest priority still-open bugs. These are probably fairly straightforward reports -- maybe it would be good to link them on the bugzilla front page?
I tried subscribing to wikibugs-l for a while, but there was too much noise: state changes, CC list changes, comments on bugs that I don't care about (without proper context), etc. I have a saved search to show new bugs, but there's no way to tell which ones I've read and what my backlog is. I also have saved searches for particularly important extensions that I maintain (OggHandler and CentralAuth), but it's easy to forget to look at them for a while. So there's room for some software improvement there.
For OggHandler, I automatically get assigned, so I get emails. But not for a whole lot of other modules and extensions that I'm primarily responsible for. I could probably add myself to the default CC list, but I don't think non-admins can do that. Having admins properly manage the assign/CC lists would be one way to improve our response.
If activity on bugzilla was more visible, it would be easier to thank people who spend time on bug triaging. (an otherwise extremely thankless task!)
Another idea would be to have regular bug triage days/events, like maybe one weekend a month, and just publicise them on here and mediawiki.org.
Is there some way to configure bugzilla to support the triage process better? An unconfirmed state perhaps?
I guess I would also like to know more generally, what can Wikimedia communities do to communicate their tech priorities to y'all more clearly? What can we do better to get clearer feedback? (Even hearing a "no" at least gives one closure. :)) Is Bugzilla the best and only method? Is it helpful if a community appoints a 'tech request manager' who acts as a filter/gateway between the developers and the wiki community?
You can vote on bugs, that feature probably isn't used enough. Maybe a "bugs by number of votes" link in the sidebar would encourage it, and make it more useful.
In general, I'm sorry to say, I think we're in a balance between making ourselves available to the community, and getting some work done every once in a while. I think we're set up in ways that distract and divert the community from actually making contact with us, except for the most motivated people, who get what they want, but are sufficiently rare that it doesn't cost us an awful lot to give it to them. I think the shell request system is an example of this.
In the case of shell requests, volunteers could help by writing web interfaces and automation scripts, to reduce the level of trust needed to fulfill various kinds of requests. Volunteer developers can also help by eliminating whole classes of requests, such as $wgImportSources, by writing less stupid core MediaWiki code.
-- Tim Starling
On Tue, Aug 5, 2008 at 12:38 PM, Tim Starling tstarling@wikimedia.org wrote:
In the case of shell requests, volunteers could help by writing web interfaces and automation scripts, to reduce the level of trust needed to fulfill various kinds of requests. Volunteer developers can also help by eliminating whole classes of requests, such as $wgImportSources, by writing less stupid core MediaWiki code.
I think there's some stuff in the works here. A web interface for group rights, and a more general (but WIkimedia-specific) extension is half-done by Victor.
On Tue, 2008-08-05 at 12:38 +1000, Tim Starling wrote:
Brianna Laugher wrote:
It is difficult to "see" activity on bugzilla, a la Recentchanges. (I guess if you are subscribed to wikibugs-l you see everything...) for example there is no straightforward way (ie link from the mainpage) to see the most recently entered bugs, or the most recently closed bugs, or the highest priority still-open bugs. These are probably fairly straightforward reports -- maybe it would be good to link them on the bugzilla front page?
I tried subscribing to wikibugs-l for a while, but there was too much noise: state changes, CC list changes, comments on bugs that I don't care about (without proper context), etc. I have a saved search to show new bugs, but there's no way to tell which ones I've read and what my backlog is. I also have saved searches for particularly important extensions that I maintain (OggHandler and CentralAuth), but it's easy to forget to look at them for a while. So there's room for some software improvement there.
<snip>
I found using a RSS reader subscribed to gmane feed of wikibugs-l allows a easy and quick overview of what's new etc. while avoiding all the noise for things I don't care about.
KTC
On Tue, Aug 5, 2008 at 12:38 PM, Tim Starling tstarling@wikimedia.org wrote:
In the case of shell requests, volunteers could help by writing web interfaces and automation scripts, to reduce the level of trust needed to fulfill various kinds of requests. Volunteer developers can also help by eliminating whole classes of requests, such as $wgImportSources, by writing less stupid core MediaWiki code.
Wikia has developed an interface to all those variables like $wgImportSources. You could easily allow stewards or any other user group to edit any that are deemed safe for that group to be editing.
The extension is available in our new public SVN at wikia-code.com.
https://svn.wikia-code.com/wikia/releases/200808.2/extensions/wikia/WikiFact...
Angela
On Mon, Aug 4, 2008 at 10:38 PM, Tim Starling tstarling@wikimedia.org wrote:
I tried subscribing to wikibugs-l for a while, but there was too much noise: state changes, CC list changes, comments on bugs that I don't care about (without proper context), etc.
FWIW, Gmail's conversation view makes context no problem.
Is there some way to configure bugzilla to support the triage process better? An unconfirmed state perhaps?
There is such a state, but I think it's not used on our Bugzilla because everyone has the "editbugs" permission. Any bug filed by someone with "canconfirm" or "editbugs" appears to be automatically confirmed.
On Tue, Aug 5, 2008 at 12:18 AM, Brianna Laugher brianna.laugher@gmail.com wrote:
How many bugs are entered, on average, each week, or month?
It seems to be about ten a day.
For bugs that are resolved/verified/closed, what is the median time for a bug to reach that state?
I have no idea on this one. It ranges from seconds to years. Of course, you're skewing it down a lot by only including bugs that have actually been resolved at some point. It might be better to include those as "infinite" when computing the median (which works, since fewer than half of all bugs are unresolved).
Actually how many bugs in total are there, and how many are in some closed state and how many are in some open state?
There are 15,048 bugs, of which (as Chad notes) 2,121 are open.
While googling for info about Bugzilla I saw someone mention the idea of introducing a NEEDSMOREINFO status or resolution. This could be a good idea because then people who want to help improve bug reports can easily find which ones need work.
I would say that the major problem with bugs is getting people to help fix them, not getting people to figure out what the problem is.
I was thinking for us, a status/resolution like HISTORICAL might be useful too, if somehow reports without activity for > 2 years could be automatically closed as HISTORICAL.
But some of those are still valid.
I created a page http://www.mediawiki.org/wiki/Bugzilla_products_and_components to describe some of the categories. I would appreciate clarification on Wikimedia>Downloads, Wikimedia>Usage Statistics and Wikimedia>wikibugs.
The descriptions for the components are given here:
https://bugzilla.wikimedia.org/describecomponents.cgi
Overall, Bugzilla is slow, lacks features, and isn't designed for our setup. I wonder if another piece of software might be more useful at some point. Supposedly Launchpad is going to be open-sourced within twelve months -- I rather like it, although mainly just by comparison with Bugzilla.
How many bugs are entered, on average, each week, or month?
For bugs that are resolved/verified/closed, what is the median time for a bug to reach that state?
Actually how many bugs in total are there, and how many are in some closed state and how many are in some open state?
While googling for info about Bugzilla I saw someone mention the idea of introducing a NEEDSMOREINFO status or resolution. This could be a good idea because then people who want to help improve bug reports can easily find which ones need work.
I was thinking for us, a status/resolution like HISTORICAL might be useful too, if somehow reports without activity for > 2 years could be automatically closed as HISTORICAL.
Who does have access to the admin side of Bugzilla? Is there anyone primarily responsible for it before Brion?
Looking at the Products, I notice that there is an "Issues" Product that is no longer offered when entering a new bug. https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Issues&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
I suggest that this should also be done (ie, these Products should not be offered for new bug reports) for dbzip2, Kate's Tools, Logwood (apparently Logwood is http://www2.knams.wikimedia.org/ ? which says "sorry, the statistics are offline for the moment" in a rather permanent way anyway)
Also, it would be a good idea to add a link to the toolserver bugtracker ( https://jira.toolserver.org/ ) to direct users there for bugs relating to toolserver tools.
I created a page http://www.mediawiki.org/wiki/Bugzilla_products_and_components to describe some of the categories. I would appreciate clarification on Wikimedia>Downloads, Wikimedia>Usage Statistics and Wikimedia>wikibugs.
Also, what's the story with the 'Wiktionary tools' Product? They are using it for their site JavaScript scripts, is that the story?
And while I'm here... :) What is "My Requests" anyway? I think this was introduced with a Bugzilla upgrade. I understand "My bugs": bugs I reported - and "My votes": Bugs I voted for.
I noticed in the preferences there is an option "Enable tags for bugs" which has "Site default (off)". I would find this useful for tagging bugs that particularly affect Commons. Or maybe I should ask for a keyword to be added? https://bugzilla.wikimedia.org/describekeywords.cgi Any thoughts about what the limits on the Keywords field should be?
thanks, Brianna
2008/8/5 Brianna Laugher brianna.laugher@gmail.com:
How many bugs are entered, on average, each week, or month?
For bugs that are resolved/verified/closed, what is the median time for a bug to reach that state?
Actually how many bugs in total are there, and how many are in some closed state and how many are in some open state?
Actually, wondering how to answer these questions, I just found http://www.bugzillametrics.org , a bugzilla addon which is meant to provide various configurable statistics and charts. It might help :)
2008/8/5 Nicolas Dumazet nicdumz@gmail.com:
2008/8/5 Brianna Laugher brianna.laugher@gmail.com:
How many bugs are entered, on average, each week, or month?
For bugs that are resolved/verified/closed, what is the median time for a bug to reach that state?
Actually how many bugs in total are there, and how many are in some closed state and how many are in some open state?
Actually, wondering how to answer these questions, I just found http://www.bugzillametrics.org , a bugzilla addon which is meant to provide various configurable statistics and charts. It might help :)
I also found some other addon things listed here: http://wiki.mozilla.org/Bugzilla:Addons
...among them, http://www.mediawiki.org/wiki/Extension:BugzillaReports *cough* maybe we should enable this on mediawiki.org ? The screenshots look reeeeeally nice. Subject to code review, of course...
Brianna
On Tue, Aug 05, 2008 at 02:13:01PM +0200, Platonides wrote:
Brianna Laugher wrote:
And while I'm here... :) What is "My Requests" anyway? I think this was introduced with a Bugzilla upgrade. I understand "My bugs": bugs I reported - and "My votes": Bugs I voted for.
I think they are "bugs i am assigned".
Personally, I would assume "My Bugs" to be "bugs I am assigned" and "My Requests" to be "bugs I filed".
Cheers, -- jra
On Tue, Aug 5, 2008 at 12:18 AM, Brianna Laugher brianna.laugher@gmail.com wrote:
How many bugs are entered, on average, each week, or month?
For bugs that are resolved/verified/closed, what is the median time for a bug to reach that state?
Actually how many bugs in total are there, and how many are in some closed state and how many are in some open state?
For MediaWiki alone, there are currently 2121 bugs in the NEW/ASSIGNED/REOPENED status, which is the normal status for any non-completed bug. See http://tinyurl.com/5qxksb.
The problem with bugs is that they can't always be compared. A bug open for a year might be in that state for any number of reasons. Lack of interest is one, difficulty of solving the problem is another. Some bugs aren't relevant anymore.
For those who aren't aware, there's a bugzilla keyword called "testme" that is useful for putting on old bugs that may or may not be fixed. Sometimes bugs are no longer bugs, because they were accidentally fixed (ie: Fixed but the fixer was unaware of an open bug for it), or the bug becomes a non-issue entirely due to a rewrite, etc.
A good effort might be spent in trying to clean up the old bugs. Find out if they're relevant, get updates, and try to put them behind us.
-Chad
wikitech-l@lists.wikimedia.org