On Sun, Nov 28, 2010 at 2:03 AM, Stephen Holt <stephen.h...@gmail.com> wrote: > > On Nov 27, 2010, at 11:22 PM, Peter Hosey wrote: > >> On Nov 27, 2010, at 21:18:42, John Bailey wrote: >>>> 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. >> >> Currently, that time (of helpers as well as developers) is wasted on closing >> duplicate tickets. On Growl, we do exactly what Jordan has suggested—use >> Google Code, file tickets ourselves—and we have nearly eliminated duplicate >> tickets*. I can't predict how well such a system would scale to Adium, but >> it's been working very well for Growl. > > > I'd like to point out that this is not a factor of using google code in > itself, but by merely closing ticket creation to a relatively few number of > people. I also question how much additional time that would add by requiring > people (developers or helpers) to much more attentively track issues reported > though side-channels (forums, email, irc, twitter, etc). I am not convinced > this would be a net time saver for an application as complex as Adium. > > Additionally, this policy seems very hostile to our users, considering our > current policy on bug reporting. (By which I mean, taking ticket creation > away, not the idea in abstract.) It is important to remember that many very > valid bugs are discovered by users with different use cases and habits than > the developers, in the absence of a VERY active development community (with > developers able to devote their full time to the project) I feel like this is > not a communication path we can shutdown casually. > > Adium is not a system service you hardly ever think about after installing, > it is an application our users intentionally use every day to do stuff, and > having enfranchised users is important. I believe allowing user created > tickets is important for this. > >>> Additionally, how… do you achieve integration between the mercurial >>> repository and Google Code so that you can close tickets with a commit >>> message? >> >> I'm pretty sure GCH doesn't support this. At any rate, we're not using it on >> Growl, since we primarily host our repositories ourselves (our GCH default >> repo is a mirror of our development repo). > > > Knowing which ticket a commit is related to (and the inverse) is a very very > important thing, and from a development perspective non-negotiable for a > project the size of Adium. If we cannot associate tickets and commits from > check-in messages, than I'd say this is a deal breaker for any alternative > system, including google code. > > That said, I wouldn't mind being able to better track branches and forks of > our repo within our management system—especially if we want to encourage this > development paradigm. (I would suggest something like bitbucket, however > they seem to still be having some occasional reliability issues.) > > Overall, I'd say if we can't find a better system we do what work we can to > update our own trac more maintainable. Also, I agree with Colin and John in > that having our own system we have complete control and ownership over has > intangible benefits. >
I don't think Peter is advocating google code, he's just referencing the fact we use google code for tickets with Growl in a very effective manner, in a way we believe users want to interact with us (i.e. not through tickets). To me it's a waste of valuable time on one or more than one person's time to maintain trac. Updating always seems to bring other random new bugs, which take weeks or months to get over. Bringing in others to work on it that work on trac itself isn't really an option anymore, as those people are also busy with other things now. We opted with Growl to change the way we do things because none of us really thought users much liked filing tickets, and because none of us had time to keep trac up to date anymore. We allow them to file tickets, but most people just don't want to from all appearances. What you call intangible benefits are to me very tangible benefits. Users no longer have to learn multiple systems to interact with us on the Growl Project, whereas on Adium they have to learn the forums, or email or irc, AND trac. How many times have people said "hey this is my first time using irc" and then said something, and then have been told to use trac, only to find out they have to learn how to use that as well? Adium already has very active people who are already in all of these systems every day. I'm not sure what the major difference will be, except for better quality development tickets that have already been vetted in an area where the users are more comfortable. What I'm talking about could be done on google code, bitbucket, jira, or even a very well done text document system with folders and files. And yes trac can be used to accomplish the same thing. Chris
