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