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?slide=55 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/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
