On 12 May 2012 19:40, MZMcBride <z(a)mzmcbride.com> wrote: This is why I suspect the real answer is someone has to write something custom for WMF requirements (just as Bugzilla was something custom for Netscape requirements, and has ossified in that shape). And it'll *still* *really suck*, because all software does. - d.

Steven Walling wrote: I'm not following you (and I'm not sure you're following me). Wikimedia's response to the "gather user feedback regarding the site" issue has been MoodBar, which, regardless of the demographic I happen to sit in, looks ridiculous. I can find a number of people from other demographics who agree. You write that MoodBar wasn't built to be a general purpose issue reporting tool. But you also write that hundreds of editors are successfully reporting issues and receiving responses from other editors. Something isn't aligning here. As I said, a generic reusable feedback tool that doesn't treat our users like retards would be cool. MoodBar _might_ be version 0.1 of this concept, but it needs a lot of work. MZMcBride

On 12 May 2012 21:25, K. Peachey <p858snake(a)gmail.com> wrote: It's horrible, but it mostly works. It occurred to me "wouldn't it be nice if Linus Torvalds had decided he really needed bug tracking done right and written a solution". He didn't write a solution, but he did rant: http://yarchive.net/comp/linux/bug_tracking.html We're complaining about the reporting. How is Bugzilla for connecting developers and bugs? How do developers actually get connected to problems? Particularly problems where the reporter isn't clear on the component. - d.

David Gerard <dgerard(a)gmail.com> writes: You do not want Linus Torvalds writing tools meant for end users. One only has to look at the struggles our development community (a technical audience, to be sure) has with using git to see the truth in this. Linus is a very smart man, but this does not mean he is the right person to design a bug tracking tool for end users. Mark.

MZMcBride <z(a)mzmcbride.com> writes: I haven't stopped thinking about these and even discussed it some with Summana last week. I was thinking along these lines and, in the spirit of getting *something* started, just started at the first step: https://www.mediawiki.org/wiki/Bug_management/Workflow Since I mostly deal with Bugzilla, I'm most familiar with that. Someone turned up this page last week: https://bugzilla.wikimedia.org/enter_bug.cgi?product=Tools&format=guided I plan on looking at this and the other work Mozilla has done to see if it would be useful. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

On Sun, May 13, 2012 at 9:26 AM, Platonides <platonides(a)gmail.com> wrote: +1. This is probably the biggest problem I have using bugzilla as an occasional, non-technical user :) If there's any way to tie the login to SUL that would be cool, but just providing more explanatory messages would be helpful! -- phoebe

TL;DR: Reduce number of fields in our BugZilla. Simplify access to search filters. See also https://www.mediawiki.org/wiki/Bugzilla which covers a fair bit for newbies. Doesn't make BugZilla better, but it does offer a guide for new users. Regarding target audience. I think it is fair to say that our Bugzilla is primarily intended for developers (be it staff developers, volunteer contributors developing core and/or extensions, or other interested tech-savvy users who are an editor on a MediaWiki-powered site or maybe own their own MediaWiki site). Not readers or editors of MediaWiki sites themselves, directly. MediaWiki sites (e.g. English Wikipedia, or your-wiki.example.org) have a local place for feedback. For Wikimedia wikis, this local place for feedback would be the village pump. Or maybe a generic feedback tool. Not BugZilla. I don't think the issue tracker that developers use should be designed so that a reader can figure out that a spelling mistake should be reported/fixed on translatewiki, or that a bug in the watchlist should be reported on "MediaWiki core > Watchlist", or that a feature request for whatever aborted his edit should be filed under "MediaWiki extensions > AbuseFilter". Readers are best leaving comments in a discussion forum. And users can help each other figure out whether there is a way already or maybe the user did something wrong. Anyone participating in a local discussion environment who feels technically responsible for the site (site-admins) or are tech-savvy community members (basically anyone who would know what a MediaWiki extension is and understand Special:Version's content).. those detect "bugs" and "feature request" when they appear in local fora and they report them upstream to the software bug tracker. Don't get me wrong though, I agree completely that BugZilla feels like a complete hack in the front end. Even for those that are the primary intended audience (anyone who knows which product/component may be relevant and what a bug report should contain), it is still an unusable nightmare in many aspects. And even for those that aren't the primary intended users of the bug tracker, to outside users it should still be easy to follow and understand the progress, without necessarily knowing how or wanting to participate. And currently neither is easy in BugZilla. For the developer/Bugzilla side of issue tracking, one of the main problem with Bugzilla infrastructure is in my opinion its complexity and over-organization of meta data[1]. I think the only fields we need as key/value pairs are: - Component - Title - Assignee - Target Milestone - Keywords - Dependency tree And of course general timeline items like attachments, comments, overal open/close status and CC. And considering the large scope of our Bugzilla install, the component category ("Product") may also be justified. And the voting system can be used to prevent the useless +1 comments. Assignee should be empty by default, only set when going to be worked on. Current "Default assignee" should in most cases be default CC. Then we won't need status "ASSIGNED" anymore (which is currently often forgotten, but due to the "default assignee" stuff, one can often not see whether it's really on someone's list). I'm convinced all other fields can be done without and removing them will improve the workflow of the developers and the Bugmeister. Including, but not limited to: - Platform (Hardware/OS) - See also - Web browser - URL These are rarely used and can just be put in the comments. Maybe URL is a nice one to have aggregated to the top of the bug view. But even then it is limited to a single url only (and has no label). Should still have a comment, so might as well not have that field. - Priority - Severity Use milestones and keywords instead ("MediaWiki 1.20.0 release", "code-update-regression", ..) Those are more descriptive and easy to track and understand. The only useful key-value of those is "severity: enhancement" to distinguish between a bug and an improvement, but we can just use a keyword for that. - Close values (RESOLVED, FIXED, WORKSFORME, VERIFIED, DUPLICATE, ...) Close reason and addendums (like "verified") can be put in comments. Plain Open/Close is all we need. Check out this presentation by Zach Holman (from GitHub) "How GitHub uses GithHub to build GitHub". It is about how they work internally at GitHub (and a bit about how GitHub helps them to do that, but it could be "How Wikimedia uses [Code review, MediaWiki.org, Mailing lists, Bugzilla] to build MediaWiki" :D). * Video: http://zachholman.com/talk/how-github-uses-github-to-build-github Specifically the section about Issues (slide 55 and on): * https://speakerdeck.com/u/holman/p/how-github-uses-github-to-build-github?s… Note that the navigation portal[2] I recently created for BugZilla (mostly for my own use, but you may find it useful too), encourages the above workflow. All that matters there is the product, milestone and whether it is open or closed. And for longer lists, possibly focus on regressions first. That's pretty much all that matters from an organizational perspective. I plan to create a similar portal view for the developer perspective of an individual product. There component, bug/feature/regression distinction and milestone would be the focus of the queries. If BugZilla would make it easier to create advanced searches, such portal wouldn't be needed (you'd click a few buttons and have it). Take a look at a GitHub project issue tracker. All it has is titles, assignee, milestone, open/close and labels. And all can be queried from the overview with a single click. -- Krinkle [1] I know that many of these can be disabled in BugZilla's administration panel, and I think we should indeed start phasing some of them out. [2] https://toolserver.org/~krinkle/wmfBugZillaPortal/

On May 14, 2012, at 5:04 AM, K. Peachey wrote: Well, one doesn't need a URL field to link to the local discussion. One can just put that in a comment. Which many do (even in Site requests). -- Krinkle

In the bug genie, we've added functionality called "teams" to address these kind of needs. Anyone can be a member of any number of teams, and teams can be assigned to almost all the fields a user can, such as "owner"/"assignee", etc. This goes for both issues, projects, components and more. This makes managing users joining and leaving much easier, as well as monitoring and subscribing to updates on interesting topics/components. I think at least Redmine also has something similar. -Daniel André On Tue, May 15, 2012 at 1:35 PM, Andre Klapper <andre_klapper(a)gmx.net>wrote;wrote:

On Tue, 2012-05-15 at 09:33 -0400, Mark A. Hershberger wrote: Can I (average user) add myself to that default CC list for a component (I am not aware of any way), or do I need to first need to find out that "default CC" exists, somehow find out who and how to contact for getting added to it (and then somebody has to add me and respond to my request) without losing motivation on my way to achieve all this? :-/ andre -- Andre Klapper (maemo.org bugmaster & GNOME Bugsquad) http://blogs.gnome.org/aklapper/

On Tue, May 15, 2012 at 4:31 PM, Chad <innocentkiller(a)gmail.com> wrote: Wut, there are MediaWiki installations runing on HP-UX? And we have developers equipped to work on bugs for that platform?

Krinkle <krinklemail(a)gmail.com> writes: I talked for a bit about this with Krinkle today. I think part of the problem with the complexity of the fields (and, yes, Bugzilla fields are too complicated) comes from the different roles people have when they come to Bugzilla. Making Bugzilla work for everyone means a bit of complexity. Work can certainly be done on the UI to help alleviate this, but I think understanding the different perspectives is a first step to working on the UI. I see three different ways of looking at the data in Bugzilla: Developer -- What can I work on right now? What is the next think on my list of TODOs? Where can I put items that need to be worked on later? Director/Manager -- What set of work needs to get done before my next release? What is blocking my next deliverable? For feature X, what are the different things that need to be implemented? End User/Bugmeister -- How can I report current problems? Where can I track progress on the resolution of a problem I'm interested in? How can I make sure people with the power to fix the problem are aware of its severity and impact? With these three views of Bugzilla in mind the Developer is going to be looking for the next action item. The Developer works with the Director to help the Director develop reasonable timelines. Bugzilla's Milestones and the priority within a Milestone are especially suited for this. The Director looks at the features that the team needs to deliver and the issues the Bugmeister has raised and works to prioritize the issues relative to the project. The Bugmeister looks at incoming bug reports (both in Bugzilla and on Village Pumps) and makes sure that urgent issues are addressed quickly, while less urgent issues are properly prioritized. The Bugmeister does not set schedules or deliverables, but needs a way to raise issues and act as an advocate for the End User. The priority and severity fields are especially suited for this. I do think the UI of Bugzilla needs work and I plan to begin addressing some of the issues this week. But I also think there is a good reason to track the data that is tracked. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

On Mon, May 21, 2012 at 3:17 PM, Tomasz Finc <tfinc(a)wikimedia.org> wrote: You can share your saved searches. I don't remember how it's done, but I seem to have searches in my list that were shared by Antoine and Sumana. Example URL: https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&… Roan

+1 If you guys can make it work then let the mobile team know. Otherwise were sticking with what works for us. --tomasz On Mon, May 21, 2012 at 3:35 PM, Chad <innocentkiller(a)gmail.com> wrote:

On 22 May 2012 00:26, Thehelpfulone <thehelpfulonewiki(a)gmail.com> wrote: I thought all users had editbugs, but there are 15525 users in total and 14573 users in the editbugs group. I imagine this right assigning must be automatic, so does anyone know why there's a discrepancy between those numbers? -- Thehelpfulone http://meta.wikimedia.org/wiki/User:Thehelpfulone

On 22/05/12 01:34, Thehelpfulone wrote: It stopped being automatically given after the issues with the bugzilla vandal (or rather, we placed existing people to the new editbugs group).

On Tue, May 22, 2012 at 2:05 AM, Krinkle <krinklemail(a)gmail.com> wrote: Yes, but having email readers do word wrap and truncation on URLs sucks. Saved searches would be ideal, but someone (maybe someone here!) needs to implement public saved searches: https://bugzilla.mozilla.org/show_bug.cgi?id=400063 It would be really great if we could coerce Bugzilla into behaving more like Redmine when it comes to milestones ("target versions" in their lingo). For example, look at this bug: http://www.redmine.org/issues/6597 Note that the "target version" is a link to "2.1.0" (as of this writing). Clicking on that link, that gives me: http://www.redmine.org/versions/47 ^ That page gives me a well-organized list of issues that are potential blockers for that release. Now look at this: http://www.redmine.org/projects/redmine/roadmap That's all of their upcoming releases. You can see at a glance what is planned for the next release, and what hasn't yet been pegged to a particular release. Also, we can go back in time http://www.redmine.org/versions/40 ^ This view gives us something to possibly use for release notes. The bar charts don't do too much for me. I'm mainly looking at this as a reasonably uncluttered view of what is associated with what milestone. Note that there are links to the same data presented in the standard query interface. Bugzilla has all of the data to generate the release note style view, but someone with some Bugzilla hacking ability would need to write the extension. Or maybe we could write a MediaWiki extension that uses the BZ API to generate these views. The only kicker would be making sure we also make the links from the individual issues actually go to the nice views. I think I might be better about using milestones if the milestone that I was using was reliably there. The 1.20wmf* milestones don't appear to be there for MediaWiki (only Wikimedia). That makes milestone kinda useless for deployment planning purposes. I'm not paying attention to the milestones now because I can't trust the queries contain all of the information I need. I've been holding off until we hire our Bug Wrangler before making a fuss about this, but I imagine the next Bug Wrangler is going to want this ability. Rob

Disclaimer: I'm the lead developer of the bug genie ( http://www.thebuggenie.com), which was marked for consideration last time this issue was discussed. This is also one of the main reasons I'm following this thread. I don't think you'll ever find a finished bug-/issue-tracking solution that caters just as well for newbies and developers. The main reason is (of course?) that most issue tracking software is written for developers, by developers with little or no experience or thought as to what makes a good end-user experience. Also, most issue tracking tools are *made deliberately* to work best for developers - with human (end-user) interaction kept to a minimum. That's also why most issue tracking solutions end up looking like glorified (not the good kind) spreadsheets (Mantis, Flyspray, others?), something the IRS would want you to fill out (BZ, OTRS, RT, others?), or some kind of bastard child in-between (The Bug Genie, Redmine, Jira, Fogbugz, others?). Each of those approaches have their strengths, but unless you want to build something like getsatisfaction.com - trying to be both completely non-technical for non-technical users ("This issue makes me sad"), and at the same time try to give power-users or developers good tools - then you're gonna have to just figure out which issue tracking solution sucks least, and then go with that. There's only so much styling can do to hide the techie stuff from non-techie users, but you also don't want to hide all the techie stuff away so your developers are dumbed down. It's a hard line to find, and I think neither we, Mantis, BZ or any others really "do it right". Some issue tracking systems will want to keep a strong focus on the user experience for both non-techie users as well as developers, whereas others really don't care that much. Licensing issues aside, it's a tricky issue to find the right balance - in the end, you'll probably end up figuring good old BZ does the trick - and if it's the solution that sucks the least for you, then that's the one to go with. All developers probably have their pet issue tracking system(s), and can go on and on about the wonders of it. I could go on and on about why TBG is a really good solution - but just saying "TBG is great, we (you) should all use that" really doesn't show much insight. I hope I can contribute something to the discussion - I certainly know what TBG's strengths are, at least in relation to the WMF - where it would be a good fit and where it would be a bad fit. Regards, Daniel André Eikeland On Mon, May 14, 2012 at 8:45 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com>wrote;wrote:

On 14 May 2012 09:10, Ryan Lane <rlane32(a)gmail.com> wrote: It is true: all bug trackers suck ... ... however, some suck even more than others. Given this, it should be possible to point it in the direction of sucking less. What do we need to do to improve Bugzilla to our ends? What are the bugs in our Bugzilla installation? Can we agree on them? Is there anyone to work on them? - d.

Thats actually quite an interesting thought, and it could well be true, even if it is the opposite of the Wiki philosophy. On the other hand, it might also be true that non-developers do find bugs, but fail to report them exactly because of the BZ user experience. It's quite important that reporters don't 'get in the way' of development. Keeping them out of the devolopers shouldn't be done by erecting walls of artificial difficulties - which is what BZ'ed user experience is, it hides the difficulty of finding and properly reporting a bug in itself behind the difficulty of going through the technical process of reporting a bug. How it should be done is a more difficult question though. Hardly anyone equipped to do proper triage from the firehose of a low-boundries bugtracker is interested in actually doing that triage (see also: code review) On Mon, May 14, 2012 at 5:46 PM, Diederik van Liere <dvanliere(a)gmail.com> wrote:

On Mon, May 14, 2012 at 9:19 AM, Risker <risker.wp(a)gmail.com> wrote: This is a lot more than a side issue. I think discussing enhancements, permissions changes, and other things that aren't strictly bugs is the worst thing about Bugzilla. These issues are often tendentious without subjecting them to Bugzilla's very clunky commenting system that aggravates the problem in so many ways. The recent change to the watchlist and history functions on English Wikipedia is a good example of this problem, as is the enormous discussion on the bug requesting article creation permissions changes for EN-WP. Steven

On Mon, May 14, 2012 at 4:46 PM, Diederik van Liere <dvanliere(a)gmail.com>wrote;wrote: specific context of Wikimedia I've found a big pile o'bugs through user intervention. With New Page Triage/New Pages Feed alone, 16 bugs and enhancements were identified in the first 24 hours, all from non-technical editors. That number has continued to grow - again, from non-technical users. If we direct them to other support channels, the bug *still* has to end up in bugzilla. The only difference is we're relying on developers, technical users, the bugmeister and others to constantly monitor and look at a plethora of channels and report things, which'll suck in their time and add another link to the chain. Every time you add relays, data gets lost.