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

How we could improve things
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.