Requests for comment/Overthrow Bugzilla

Request for comment (RFC)
Overthrow Bugzilla
Component	General
Creation date	18 August 2012
Author(s)	Isarra, Jack Phoenix
Document status	implemented we migrated to Phabricator 2014-11-23 See Phabricator.

Tracked in Phabricator
Task T62124

Bugzilla sucks.^ref

That's not to say it doesn't work in general, nor that it isn't currently the best available solution, but for Wikimedia's purposes, it just doesn't work. This is not a close-knit group of OS developers, and it is not a company with devs who can walk across the hall and discuss the bugs in person over the nearest potted plant; this is a large pile of random volunteers from all over the world working with a smaller pile of staff mostly, but not entirely, based around more a more specific area, creating and maintaining a platform for a whole honking lot of other really random and very opinionated volunteers from all over the world.

And Bugzilla just doesn't work for that.

Problems with Bugzilla

It requires a separate registration; you can't just use your CentralAuth credentials to log in and enter a bug
Lack of integration with MediaWiki in general
Usability issues
Communication issues
Confusing and often opaque workflow
Implementation in Perl
Lack of e-mail privacy (bug 163551 has an initial patch that might end up in 5.0)
Because there's no revision history, you can't edit your comments after posting them, so if you mess up a link or something you can't fix it (we probably want to limit the ability to edit comments to prevent abuse anyway)
The previous point would be alleviated if there were a preview option before submitting comments, something that's also lacking (bug 40896 has an initial patch that might end up in 5.0)
Domains allowed on the see also field are validated against a whitelist, but that whitelist isn't configurable, not allowing the addition of php.net bugs (will be fixed by upgrading to 4.4)

Grand plot

Someone would probably say: "let's switch from Bugzilla to [insert your favorite bug tracker here]". Sadly that doesn't really work, because Bugzilla is pretty much the best open source bug tracker out there. This leaves two viable options:

A proper solution would be an inhouse bug tracker (preferrably one written in PHP, as that's what MediaWiki itself is written in). Sadly this requires a lot of researching, developers and their time, but it would be worth it in the long run; think of MediaWiki and just how popular, flexible and generally awesome it is nowadays.
Another possibility would be to take Bugzilla and make it suit our needs — this would probably result in a fork of the program or, depending on how flexible it is, an entirely new front-end on top of the existing infrastructure.
We can just keep using Bugzilla which actually rocks - since everyone knows how to use it and just accept improvements from upstream as they come.

P.S. using it from eclipse is plenty fun too!

General scheming

But what, specifically, would we want of this new tracker, and how should we proceed to get that? And what concerns do we need to consider along the way? There are both developers and users involved, here, so a solution serving both is a must, but these people also come from all backgrounds, and all regions of the world, but probably not any regions off-world.

Users to consider

Volunteer developers
Wikimedia project contributors
Wikimedia project readers
Wikimedia staff
Third-party project sysadmins
Third-party project contributors and readers
Others?

Necessary components

Stuff Bugzilla has
Stuff Bugzilla doesn't have

Viability

Writing a new thing, who would write and maintain it? Where would the overall schema come from? How would the current content translate over? And modifying Bugzilla, what is actually supported? Who would implement the changes and maintain them (especially given that it's Perl), and would updates to the original Bugzilla still be compatible?

Need input from folks who would know these things...

How would writing a new bug-tracker serve the goal of the foundation? Why is the language even an issue and why php and not Erlang or scala or lua?
What of all the time spent by people learning the old system that would be a sunk cost. How long would it take until everyone is as productive again reporting and updating bugs.
What would be the cost and expected ROI for such a project?

General / random ideas

Perhaps it would take the form of a core tracker, with a MediaWiki extension for users to interact with that and submit bugs directly from their various wikis? SUL should still be involved when going to the tracker proper, of course; alternatively.
Create the entire issue tracker as a MediaWiki extension. Integrate it with Gerrit's successor, which will also be a MediaWiki extension.
Threading comments, and different categories for triaging information, fix progress, and general comments (integration with Echo?).
Notifications when fixes are actually made.
More idiot-friendly interface. — “No bloody idea” is a perfectly valid option, thankyouverymuch.
Cake.
Etc.

Concerns

This is completely insane.
Something about conversion. Shouldn't be a big deal; ideally, convert everything, but if that's impracticable, just phase out Bugzilla the way we're phasing out SVN now.
Something about how this is COMPLETELY INSANE.
Cake is expensive and sometimes a lie.

Some comments by the bugwrangler

It requires a separate registration; you can't just use your CentralAuth credentials to log in and enter a bug
1. Somebody should work on Extension:AuthBugzilla to fix this.
  Not possible with Bugzilla's current implementation. The way it handles accounts, including the lack of email privacy and requirement of using an email address, makes it completely incompatible with most mediawiki installs, including Wikimedia's. Given that the bug about email privacy is clearly a very low priority on the bugzilla end, this blocker is unlikely to be resolved any time soon unless someone on our end could explicitly look to it. -— Isarra ༆
  1. Login does not have to be an email address according to https://bugzilla.mozilla.org/show_bug.cgi?id=240845 . For Single-Sign-On see e.g. http://www.bugzilla.org/releases/2.20/new-features.html#env (supporting what Apache supports) or the Env4AD add-on on https://wiki.mozilla.org/Bugzilla:Addons ... I don't have enough knowledge of authentication systems to provide a statement specifically for MediaWiki integration though. --AKlapper (WMF) (talk) 10:07, 25 March 2013 (UTC)[reply]
Lack of integration with MediaWiki in general
1. Too vague to comment or fix. Needs specific examples.
  Can't report bugs from on a wiki, can't search, can't easily link, need different accounts... resolve that last one, however, and we could probably write whatever MediaWiki front-ends for this we want. Which would be totally awesome, I might point out. -— Isarra ༆
Usability issues
1. Too vague to comment or fix. Needs specific examples.
  Example: the search is atrocious if one doesn't know what they're doing. And nobody new to it is going to have any idea what they're doing. Most people who aren't new to it don't seem to have much idea what they're doing either, though at least this makes people who do that much more popular.
  
  That said these are generally just little things that would be pretty easily resolved. A lot of them probably have bugs filed already, and others will be reported as well as they come up. -— Isarra ༆
  1. "atrocious" is as unhelpful as "usability issue". More or less everything can be hard if you don't know what you're doing. SO what's your concrete, specific issues with the simple search in Bugzilla? --AKlapper (WMF) (talk) 10:07, 25 March 2013 (UTC)[reply]
Communication issues
1. Too vague to comment or fix. Needs specific examples.
  Discussion interface and status reporting need work, but this could also be relatively easily resolvable. -— Isarra ༆
Confusing and often opaque workflow
1. Too vague to comment or fix. Needs specific examples.
  I found it too confusing to be more specific. -— Isarra ༆
  1. I found it too vague to fix it then. --AKlapper (WMF) (talk) 10:07, 25 March 2013 (UTC)[reply]
Implementation in Perl
1. How is that a problem and for which group of people?
  It's a problem for anyone who would want to work with it with MediaWiki - for instance writing something for it to deal with mediawiki better such as with common account handling. Most developers here couldn't even try to hack it because the codebase is entirely different, much as we might want or need to. -— Isarra ༆
  1. While having it in PHP (or another commonly-used language amongst devs) would be a positive, I don't think having it in Perl is a negative. It's a sane and widely-supported language with plenty of documentation. I'd also imagine we have more than several developers who can write Perl if the need serves. "It's codebase is entirely different" -- well of course, anything that's not MediaWiki or an extension is bound to be alien to us. We use lots of tools that we don't develop ourselves, thus making the codebase "different." ^demon^{[omg plz]} 03:30, 24 September 2013 (UTC)[reply]

Perl is a easy language to learn and there are plenty of perl hackers in the wild who use bugzilla. I guess that there is a greater underlying issues when it comes to improving Bugzilla. ~~~~

Lack of email privacy
1. True. See https://bugzilla.wikimedia.org/show_bug.cgi?id=148 and https://bugzilla.mozilla.org/show_bug.cgi?id=218917
2. email is not private by definition, protocol, pgp NSA etc.