I'm a little late to this as well, but I didn't see any mention of Trac ( http://trac.edgewall.org/ ) in this thread. It has several things in its favor: - Open source - Python - Great community - Easily hackable, very flexible, and as a result... - Tons of open-source plugins for all your needs
At the last place I worked, we wanted a whiteboard-style SCRUM tool for laying out the backlog and allocating it into buckets. We wrote and released a plugin for Trac: - https://github.com/clearspring/tracboard I've always felt that when it comes to bug-tracking and project-management software, every org is different, and as a result, it often makes sense to roll your own to reflect your workflow. I think the best projects are the ones that make it easiest to do this without reinventing the wheel. Trac's ease of customizability is a big plus. -- David Schoonover [email protected] On Mar 3, 2012, at 6:21 PM, Rob Lanphier wrote: > Hi John, > > I'm happy that you're looking at this, because I can't say that I'm > thrilled with Bugzilla, and I'd be happy to see a better alternative > to it. However, I also kinda agree with Chad: it's not that I love > Bugzilla, but rather we haven't yet found a system that's better > enough to invest in a migration. That's been the state of things for > so long that it's very easy to get cynical about it. That said, I'm > keeping an open mind, and I'm intrigued by one of your suggestions > (Bug Genie). More on that in a bit. > > One requirement I would like to place on a new system, should we go > there, is that it support Wikimedia SUL in some form. I realize that > Bugzilla doesn't support this, but the point behind this requirement > would be that if we're going to go through a painful migration, > integration with our existing login system needs to be one of the > benefits. It might mean that this project come behind some form of > OpenID provider support on the Wikimedia cluster. > > More inline... > > On Fri, Mar 2, 2012 at 5:11 PM, John Du Hart <[email protected]> wrote: >> I'm currently investigating alternative bug tracker and project management >> software for MediaWiki. To do that I'll be installing some different >> software on the Labs and importing existing bugs for evaluation by the >> development team and users. The following software is planned for test: >> >> >> - JIRA <http://www.atlassian.com/software/jira/overview> + Greenhopper + >> Bonfire > > I've got a lot of experience with JIRA that I'm happy to share > offlist. Since this has partially devolved into a discussion about > open vs proprietary, I think you should read this: > http://www.atlassian.com/licensing/license > > ...and not install it until you have. There will be a test ;-) > > Generally, it's going to take a lot to convince me that a proprietary > solution is going to work for us. > >> - YouTrack <http://www.jetbrains.com/youtrack/> >> - The Bug Genie <http://www.thebuggenie.com/index.php> >> - Redmine <http://www.redmine.org/> >> - ChiliProject <https://www.chiliproject.org/> > > Redmine is the one that was the frontrunner the last evaluation we did in > 2010: > http://www.mediawiki.org/wiki/Tracker/PM_tool > > There's possibly some other stuff to look at on the 2010 list. > > As I alluded to, I'm intrigued by The Bug Genie. Looks like it's > PHP-based open source, under active development for 10 years, and that > they've put some thought into the UI. I don't think that one came up > in our last eval, but it probably should have. I'd encourage you to > nudge that one higher on your list. > >> Of course, this goes back to the original request. To do this I need a dump >> of the current Bugzilla install. Is it possible for me to get this and >> under what conditions? Thank you. > > There's some confidential information in there, so possibly an NDA. > I'll talk to Sumana on Monday about this. > > One thing that I would ask of you, though, is to be mindful of our > community's actual capacity for disruptive change and > development/operations capacity in general. The reason why we dropped > this project back in 2010 was that it became clear that we were trying > to do too many things in parallel, and not doing any of those things > well. While WMF has more capacity, and you're helping out by > volunteering this work, we still might not have capacity for this > project. Even if you do a lot of the work, it will be both a > disruption for others, as well as a fair amount of work for others. > > Given we're smack dab in the middle of an incredibly disruptive change > (migrating from SVN to Git), it seems like this might be the wrong > time to do anything more than experiments. So, that's not to say > "don't evaluate other systems", but just be mindful that success might > still mean waiting until late 2012 or even 2013 for the project to > really begin in earnest. If you're ok with that, then I say "great"! > If that sounds like way too long to wait after doing a lot of work, > then I'd caution against starting. > > Rob > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
