Last modified: 2014-07-22 12:09:51 UTC
Everyone hates Bugzilla. Let's get rid of it with something better. https://www.mediawiki.org/wiki/Requests_for_comment/Overthrow_Bugzilla
(In reply to comment #0) > Everyone hates Bugzilla. Let's get rid of it with something better. [Citation Needed] Needs much wider consensus and proven replacements before its even considered.
I'm not sure this is new or unconfirmed. There's an ongoing discussion at [[mw:Project management tools]], but I believe replacing Bugzilla is firmly off the table for now. I'll note generally that Wikimedia's Bugzilla installation is about ten years old and includes a full-time staff member tasked with managing it. It's a large and complex task to replace Bugzilla given how enmeshed it is with Wikimedia's development and non-development workflows. All issue trackers are terrible. It would be a much better use of time to focus on discrete action items that could improve Bugzilla rather than seeking to simply replace it, in my opinion.
What makes them terrible? Do you think, given the information and ideas we currently have, that it would be possible to create one that isn't terrible?
> All issue trackers are terrible. It would be a much better use of time to > focus > on discrete action items that could improve Bugzilla rather than seeking to > simply replace it, in my opinion. +1. It seems like we have this discussion regularly
minus tracking. It can't be a tracking bug if it tracks nothing (?)
(In reply to comment #2) > All issue trackers are terrible. It would be a much better use of time to > focus > on discrete action items that could improve Bugzilla rather than seeking to > simply replace it, in my opinion. This. This bug isn't actionable (neither is that RfC, really). Marking this INVALID. I agree with everything said above: let's focus on incremental things we can fix rather than starting over. (In reply to comment #3) > What makes them terrible? Do you think, given the information and ideas we > currently have, that it would be possible to create one that isn't terrible? I think part of it is because you've got a lot of different users wanting a lot of different information out of a bug tracker. It's hard to do that without overloading the user with information. I'd also be firmly against us trying to embark on writing this ourselves. Bug trackers--like time trackers--are universally bad. Ours will be awful too and I have no desire to add another awful bug tracker to the dustbin of history.
I guess if we were considering writing our own bugtracker, the questions would be, What should the bugtracker do/be that Bugzilla doesn't/isn't; and is it worth the costs of programming? A few of the sub-questions were answered on the wiki page but I'm not sure a comprehensive case has been made yet.
Chad: please don't be hasty. There is an open RFC about this issue, because it's up for debate. We should probably have an open bug as well. We can close it later if the RFC fails. Until then closing it is premature. I largely agree with MZ personally, but I filed the bug for procedural purposes and to start conversation, which should happen on the RFC.
(In reply to comment #7) > wiki page but I'm not sure a comprehensive case has been made yet. Of course, sometimes the reason people don't make a convincing case is that they can't...
(In reply to comment #8) > Chad: please don't be hasty. > > There is an open RFC about this issue, because it's up for debate. We should > probably have an open bug as well. We can close it later if the RFC fails. > Until then closing it is premature. > I wasn't being hasty. This bug is hasty :) We shouldn't open a bug until there's something to *do* > I largely agree with MZ personally, but I filed the bug for procedural > purposes > and to start conversation, which should happen on the RFC. The policy discussion should happen on the RFC, right.
I, for one, welcome our new Bugzilla replacement Overlords
The ability of any random person to resolve a bug, and then any random person reopen it, is hardly making a case for why Bugzilla is awesome.
(In reply to comment #12) > The ability of any random person to resolve a bug, and then any random person > reopen it, is hardly making a case for why Bugzilla is awesome. Isn't that the wiki way? [[metawikipedia:the wiki way]]
(In reply to comment #12) > The ability of any random person to resolve a bug, and then any random person > reopen it, is hardly making a case for why Bugzilla is awesome. See my comment earlier about different people wanting different things out of a bug tracker. Being able to change states is a feature to me. Nor should any one person ever have the final say :)
(In reply to comment #14) >Nor should any one person ever have the final say :) I agree. That's why this should be decided in the RFC and not by you unilaterally closing a tracking bug for an open issue. Saying it's not actionable is nonsense. It's just not actionable immediately. There's a lot of work to be done. We lots of bugs that are like that, especially tracking bugs.
Unassigning myself for as long as the RFC is in a poor state. (And not sure how this bug report helps the RFC, but anyway.)
I don't necessarily agree with the premise that every RFC needs an associated bug report. Certainly the RFCs that are being actively worked on should have related bugs (possibly including a tracking bug), but this particular RFC isn't being worked on currently. I'll go ahead and mark this bug as unconfirmed for now. It seemed like a good fit a few hours ago and after watching this bug be reopened, um, three times, this seems like a reasonable compromise for now. :-)
http://www.mediawiki.org/wiki/Requests_for_comment/Phabricator
Being worked on; not tracked here but in http://fab.wmflabs.org/T39
