For the last months I have been going through Bugzilla and what strikes me is that we are not using it as efficiently as other communities do. In particular, there is little follow up to reported problems (as Leo mentioned as well). On the short term, I think we can have a bugathon to clean up the buglist a little bit and re-energize some community members: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? On Sat, Feb 12, 2011 at 3:41 PM, Leo <diebuche(a)gmail.com> wrote:

On Sat, Feb 12, 2011 at 1:11 PM, Ryan Lane &lt;rlane32(a)gmail.com&gt; wrote: I'm curious: is there a way that non-technical people can help with sprints like this? Documentation-building, maybe? Something else? I'm interested in development sprints, bugathons etc that involve both technical & non-technical people; I've been involved in a few and it's pretty fun. But I don't know how many useful ways non-programmers & non-developers can help. -- phoebe -- * I use this address for lists; send personal messages to phoebe.ayers <at> gmail.com *

Diederik van Liere &lt;dvanliere(a)gmail.com&gt; writes: THIS! People familiar with Wikipedia can help us suss out the real issues and make sure that real issues aren't being ignored. If this is something you're interested in doing, let me know so we can work together more efficiently. Also, at some point I want to provide a better way — better than just the complicated and confusing native Bugzilla interface — for collecting bug reports. Having the input of a non-technical user who could help us identify the really confusing -- Mark A. Hershberger Bugmeister Wikimedia Foundation mhershberger(a)wikimedia.org 717.271.1084

2011/2/14 Mark A. Hershberger &lt;mhershberger(a)wikimedia.org&gt;rg>: Actually, i enjoyed reading this string of emails from The 'Meister. That would be a Good Thing, but i must point out that it is already *relatively* easier than in some bug trackers. bugzilla.wikimedia.org is the tracker where i report more bugs than elsewhere. The second is bugzilla.mozilla.org . It's not because Firefox has less bugs (quite the contrary!) but because Mozilla's tracker requires me to fill more fields, such as steps for reproduction. This may encourage detailed reporting that helps developers solve the bugs, but it may also discourage people from reporting them in the first place. I don't have precise data about this, which means that bug reporting should be included in the next round of usability testing. (There will be another round of usability testing One Day, right?)

"Amir E. Aharoni" &lt;amir.aharoni(a)mail.huji.ac.il&gt; writes: Perhaps we could recruit some people from the he.wikipedia.org community to take problems reported (via the localized interface?) and reproduce them or act as a “translator” between developers and bug reporters? Mark.

Mark A. Hershberger wrote: to them or There is already some infrastructure for this kind of idea: https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors I didn't know about this mailing list until a few days ago, but it's a start in building the bridge between MediaWiki development and (power-)users. MZMcBride

On 2/13/2011 8:46 PM, Diederik van Liere wrote: I can totally understand the idea behind this but I think Amir brings up the concern about this best: On 2/13/2011 5:56 PM, Amir E. Aharoni wrote: Gathering all that information on a bug report form could quite clearly make it easier to reproduce bugs and may make resolving them easier but I worry that the harder and/or more complicated we make the reporting the more likely we are to scare someone away from taking the time to file the bug (which we want). I'm not totally sure where the best balance there is. -- James Alexander Associate Community Officer Wikimedia Foundation Jalexander(a)wikimedia.org +1-415-839-6885 x6716

Actually our "users" could be anyone who reads Wikipedia and notices there's something wrong with what MediaWiki is doing or thinks there is something about the ui we need to fix. They don't even have to be as advanced as a Firefox user... they could be a random "human" who doesn't even know they can install a browser other than Internet Explorer on their computer. If someone is already saying it's harder to report a bug to Mozilla about something they usually install themselves, I don't think we want reporting to be as hard when we have "users" who don't even know it's something they can install. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On 11-02-13 07:53 PM, Diederik van Liere wrote:

On 14 February 2011 04:16, Daniel Friesen &lt;lists(a)nadir-seen-fire.com&gt; wrote: A few of these come into OTRS, specifically the "technical issues" subqueue of info-en. Most aren't bug reports, a few would count as such. Getting technical information from nontechnical users is always a tricky one ... does anyone here keep an eye on that subqueue? - d.

Wow, it's difficult to unwind a middle-posted message. I think that having a wizard to make reporting bugs easier is a great idea, and will likely increase the number of problem reports you have to work with... as long as you don't get it in *my* when when I'm trying to report a bug, thank-you-very-much. :-) Making an easy interface available is wonderful, as long as you don't drive power users up the wall with it, an opinion of mine which I'm sure won't be a surprise to anyone who's watched me post here on wikitext and parsers/editors. :-) Cheers, -- jra ----- Original Message -----

I am not following this line of reasoning: how can adding guidance / instructions on how to write a good bug report turn people away? In a previous life, I have studied the factors that shorten the time required to fix a big. Bugreports that contain steps to reproduce are a significant predictor to shorten the time to fix a bug. You can find the paper here: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1507233 A systematic lack of replies is also an issue but this solution was not aimed at fixing that problem. On Mon, Feb 14, 2011 at 4:39 AM, Bryan Tong Minh &lt;bryan.tongminh(a)gmail.com&gt;wrote;wrote: -- <a href="http://about.me/diederik">Check out my about.me profile!</a>

Maybe i am not expressing myself clear, i am not talking about adding checkboxes, radiobuttons or pulldown menus, I am saying that we could add the following text to the textarea field which contains the actual bugreport: "Please describe the steps to take to reproduce the problem:" "What is the expected result:" "What is the actual result:" "If you know which version you are using or you have other information that you think might be helpful please add it as well. You can also describe the problem in your own words and not sticking to the abovementioned questions." So, again I am not saying we should add fields, we could add this text as the default text in the textarea so people have a bit more guidance when writing a bugreport. No hard checks, nothing is mandatory. On Mon, Feb 14, 2011 at 10:22 AM, Amir E. Aharoni &lt;amir.aharoni(a)mail.huji.ac.il&gt; wrote: -- <a href="http://about.me/diederik">Check out my about.me profile!</a>

On 14 February 2011 17:40, Jay Ashworth &lt;jra(a)baylink.com&gt; wrote: Any bug system has to capture everything possible, obviously. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html - d.

Diederik van Liere &lt;dvanliere(a)gmail.com&gt; writes: I don't think it would … as long as it is simply guidance and not a required field. If we pre-fill the textarea, for example, with suggestions for the sort of information to provide, then this would help. People do ask me on IRC: “What sort of information should I put?” That is the second most common response I've heard, next to “What do I select for ‘Component'? Do I have to put anything in ‘Assign To'?” I've a feeling that this is the feedback you're getting: a major part of the problem is the overwhelming amount of information people are asked for when they just want to say “When I do X, Y happens. And it shouldn't.” An UploadWizard-style guide for people to report bugs might be helpful but the first step should be to reduce the amount of information that users are asked for. Mark.

phoebe ayers &lt;phoebe.wiki(a)gmail.com&gt; writes: Bugzilla is a huge impediment to problem reporting for lay people. Even technically trained ones, like myself, look at the UI and groan. I want to do as much as possible to make problem reporting easier while still retaining some quality-control on the bug reports themselves. Mark.

BZ4 is coming? Cool. You can't *imagine* how happy I'd be to help with that project, Chad. :-) BZ3 can suck, but a couple of custom implementations of it (RH and SuSE Novell's are, I think, the ones I'm thinking of) showed that it could be implemented *well* if you put the work into it... Cheers, -- jra

On Mon, Feb 14, 2011 at 8:01 PM, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: Neither do I, Bugzilla is always going to suck. Maybe we can make it suck a little less though ;-) I mentioned this earlier today in IRC, but I'll mention it again here on- list. Take a look at the "Guided format"[0] for entering bugs. These templates can be customized, and I think we can use that as a starting point for creating nicer bug input forms (think: separate forms for enhancements vs. actual bugs). -Chad [0] https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&format=g…

phoebe ayers wrote: I don't know about others, but I personally find the Bugzilla interface to be a complete pain-in-the-ass and just generally awful. Any search of the bugs in the system is often slow and filled with noise. One way to solve this is to bypass the current Bugzilla interface altogether. In the same way that people can create neat and awesome tools using the replicated wiki databases, the Bugzilla database can (and should) be replicated to Toolserver users to allow them to have direct database access. Direct database access makes it infinitely easier to build tools that could, for example, support a better tagging system. I'd like to see all bugs that affect wikipedia, that affect en.wikipedia, that are user interface related, etc. A separate tags system would be awesome, in my view, as the one in Bugzilla currently sucks. Direct database access also would allow for better (and faster) reports that could be output in a web tool or on a wiki (with versioning!). Which bugs have the most comments? Which bugs have no comments? Some of this information is query-able from the Bugzilla interface, but as I said, it's very slow to query and getting the query written takes way more time and energy than it should (if it's possible at all). To this end, I filed a JIRA ticket with the Toolserver ops about getting the Wikimedia Bugzilla database replicated with public views: https://jira.toolserver.org/browse/TS-901 I have no tricks up my sleeve to get this moving along other than occasionally poking people about it, though. :-) MZMcBride

On Mon, Feb 14, 2011 at 4:44 PM, Leo &lt;diebuche(a)gmail.com&gt; wrote: Bugzilla actually ships with a default robots.txt that denies everything, we just never removed it. :) I don't know offhand how friendly Bugzilla is to direct indexing, but did stumble on some sort of extension to generate a sitemap (have not used it, don't know if it works well): http://code.google.com/p/bugzilla-sitemap/ Might also want to double-check if the issue of exposing commenters' raw email addresses to unlogged-in spiders has been resolved. -- brion

On Tue, Feb 15, 2011 at 10:44 AM, Leo &lt;diebuche(a)gmail.com&gt; wrote: Probably because historically you couldn't hide email addresses from anon (non logged in) users, and well not everyone is a fan of having their email harvested by bots that obey the robots file. -Peachey

* Platonides &lt;Platonides(a)gmail.com&gt; [Wed, 16 Feb 2011 00:40:38 +0100]: by There is Crawl-delay directive in robots.txt. And one may deny the robots which do not obey it. Dmitriy

We also plan to have two US-based hack-a-ton's a year, and I believe there is some form of one at Wikimania too. You don't always necessarily need to travel to another country to get to one. I don't disagree with your sentiment though. We should likely make these events easier to attend online. We already put in the effort to mark bugs before hand, and we all work on IRC while at the event, so I don't see anything stopping online participation from happening. The hack-a-tons usually don't have presentations, so that part isn't much of an issue. We can likely stream out anything that needs to be, if it comes up. I believe that in-person events are key for people to get to know one another, though. Maybe not everyone feels that way, but I definitely do. I've worked on MediaWiki for years, and I feel I know other community members much better since I've been meeting them in person, much more so than the years prior. The hack-a-tons may not be effective at bringing in new people, but I feel they are very effective at solidifying the current community that we have. - Ryan Lane

2011/2/13 Bryan Tong Minh &lt;bryan.tongminh(a)gmail.com&gt;om>: I've also read one of the articles linked in the OP, and it got me thinking about the fact that we're not only bad at responding to bug reports (although bugmeister efforts are focused on that now), but also at responding to commits. In the preparations for the 1.17 release I've seen lots of commits that were several months old and only got reviewed because we decided to work on a release. Ideally, every commit would be reviewed within a few days of being committed, so the committer can still reasonably be expected to fix any issues with it. Not letting review get too far behind HEAD is also important for doing continuous integration, something I'm really gonna push for now that I'm closely involved with the saga around deploying a new version with about 15,000 new revisions. Getting things reviewed fast ought to be doable if we set up some kind of schedule where, say, 7 reviewers are each responsible for one day of the week (or 5 reviewers for 4 36-hour chunks and one 24-hour chunk, or take turns every 100 revisions, or ...) and reassign some of their revisions to others where specific expertise is needed. This is basically what we've been doing with the last 1.17 review sprint: Mark Hershberger divided up the review queue between 4 or 5 people using tags in CodeReview, and we would each go through our queue, review what we could, and reassign the rest. Bugzilla patches are another matter, yes, but I think making sure patches get reviewed can be a Bugmeister task. We get relatively few patches through Bugzilla these days anyway. Roan Kattouw (Catrope)

Maybe we can make the bugathon part of the Berlin hackaton? On Sun, Feb 13, 2011 at 4:03 PM, Ashar Voultoiz &lt;hashar+wmf(a)free.fr&gt; wrote: -- <a href="http://about.me/diederik">Check out my about.me profile!</a>

2011/2/13 Mark A. Hershberger &lt;mhershberger(a)wikimedia.org&gt;rg>: We should definitely do this, and de facto we do this already. This is what I meant by reassigning as appropriate. However, I think it's a good idea to balance "everything else" over all reviewers, even the specialized ones. I was thinking that tying things to certain days would enforce regularity more naturally than per-directory review would. Yes, I wrote the CodeReview sign-off feature with this in mind. Roan Kattouw (Catrope)

Leo &lt;diebuche(a)gmail.com&gt; writes: This is one of the things I've been trying to do as the new Bugmeister. Every day, about 20-30 bugs are created. Especially in those cases where the bug reporter is not a MediaWiki developer or regular user of Bugzilla, I try to make sure that they hear back from me, even if it is just “Thanks for reporting this, I'll try to make sure someone looks at it.” But, to your specific complaint about patches submitted through Bugzilla, I like Diederik's suggestion: In fact, although I've been focused on the 1.17 release, I've also been thinking about the 1.18 release. This would be a great way to start addressing the creeping normalcy[1] that people have experienced with MediaWiki. I definitely want to have one or two of these bugathons during the next release cycle. If there is enough interest, perhaps we can plan something for Berlin. The other thing that will help is making more releases more often. This is one area that I want to use my new role within the community: until now, no one has been expected to make sure MediaWiki releases are made “early and often” and we were all happy enough to focus on writing new code while making software relases someone else's responsibility. More frequent releases communicate vitality to software developers. [1] http://en.wikipedia.org/wiki/Creeping_normalcy -- Mark A. Hershberger Bugmeister Wikimedia Foundation mhershberger(a)wikimedia.org 717.271.1084