dsc at wikimedia
May 21, 2012, 10:56 AM
Post #44 of 44
(234 views)
Permalink
|
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
dsc [at] wikimedia
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 <compwhizii [at] gmail> 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
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
signature.asc
