On 11/27/2010 11:49 PM, Jordan wrote: > I'd like to propose that we make the switch to Google Code for issue > tracking with the following configuration.
I'm an outsider here, but I think this warrants some commentary. <snip> > 2. We still lock out user submission of Issues, but allow voting > (star system). We encourage the use of the forums for users to submit > their bugs, following which we confirm or dismiss them. If confirmed, > then a dev creates an issue in the Google Code tracker to represent > the bug. Users who report well described bugs on the forums gain > access to the Google Code issue tracker. This is an inordinate amount of overhead. Requiring a developer to open a ticket for an issue is a waste of the developer's already severely limited time. If there are duplicate issues, whoever is responsible for ticket triage should be closing the additional reports. Remember, the ticket system is supposed to help the developers, not require them to do more work. It's obvious from the fact that Adium 1.4 took *two years* to be released that there is a severe shortage in developer time, some of which is due to developers getting paying development jobs. Consider carefully the true impact of this particular part of the proposal. <snip> > In one fell swoop we get to eliminate SPAM, deal with our ridiculous > amount of duplicate reports, stop overwhelming developers with insane > amounts of tickets to work with, and prevent the submission of poorly > described and/or unfleshed out reports (ie: no logging included). I'm > sure there's more benefits. You can always move trac.adium.im to another name and create a new trac instance to replace it. It should be possible to copy the wiki pages' current versions (the history is always in the old database) from the old trac's database to a new one. A method to deal with ticket spam has already been proposed in this thread. > The only downside is having to spend a bit of time moving our tickets > from the next couple milestones into Google Code. All others can be > left behind for reference, but not for direct use in the new tracking > system. There's also the downside that developers have to learn Google Code; they're already familiar with trac. Additionally, how, other than storing the repository on Google's servers, do you achieve integration between the mercurial repository and Google Code so that you can close tickets with a commit message? Further, does it really make sense to give up control of such vital parts of your infrastructure? Yes, there's maintenance and administration overhead, but at the same time you have complete control over both trac and mercurial as you stand now. If you move to Google's offering, you're both giving up that control and trusting them to serve in your best interests at all times. I'm not so sure I'd be willing to trust in that. John
signature.asc
Description: OpenPGP digital signature
