Requests for comment/Overthrow Bugzilla

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

 * 1) It requires a separate registration; you can't just use your CentralAuth credentials to log in and enter a bug
 * 2) Lack of integration with MediaWiki in general
 * 3) Usability issues
 * 4) Communication issues
 * 5) Confusing and often opaque workflow
 * 6) Implementation in Perl
 * 7) Lack of email privacy

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:


 * 1) 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, programmers 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.
 * 2) 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.

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 offworld.

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...

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

 * 1) It requires a separate registration; you can't just use your CentralAuth credentials to log in and enter a bug
 * 2) 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) Lack of integration with MediaWiki in general
 * 2) 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 ༆
 * 1) Usability issues
 * 2) 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) Communication issues
 * 2) 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 ༆
 * 1) Confusing and often opaque workflow
 * 2) Too vague to comment or fix. Needs specific examples.
 * I found it too confusing to be more specific. -— Isarra ༆
 * 1) Implementation in Perl
 * 2) 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) Lack of email privacy
 * 2) True. See https://bugzilla.wikimedia.org/show_bug.cgi?id=148 and https://bugzilla.mozilla.org/show_bug.cgi?id=218917