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,
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. I think the only fields we need as key/value pairs are:
- Target Milestone
- 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
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
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
- Platform (Hardware/OS)
- See also
- Web browser
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.
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
- 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):
Note that the navigation portal 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
 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.