On Sat, Mar 16, 2013 at 6:18 AM, Branko Čibej <[email protected]> wrote:
> On 16.03.2013 13:36, Ryan Ollos wrote: > > Maybe you don't think that an issue tracker should exist at all? You > > continue to suggest that we not use the issue tracker for anything as > > far as I can tell. You seem to feel that Subversion and the mailing > > list are entirely adequate, and an issue tracker would then be used > > for what? I disagree, and I can't speak for others, but I get the > > impression that I'm not alone in disagreeing. > > An issue tracker should be used for tracking issues, not for discussing > designs or writing code. That's the point Greg and I have been trying to > make. More often than not, instead of filing an issue about a minor nit, > it would make more sense to simply fix said nit in the code or > documentation or wherever. > It makes sense to have design discussions on the mailing list. In some cases we probably do have too much ticket noise. I feel we might need to make some minor adjustments in how we use the issue tracker, not do a 180. Greg's viewpoint on not using the issue tracker seems more extreme than yours, and regardless, I can see room for improvement, but can't agree with taking the specific steps Greg proposed in the 3 tickets that he objected to. I still don't see a problem with #467 and feel that tickets should be used for implementation of change requests, and should tie change descriptions to the codebase in which the changes were made. That is how companies I've worked for have used the issue tracker, that is how the Trac/Trac-Hacks community uses the issue tracker, and I think it works quite well. For this project, I don't think we need a ticket for every change, however #467 was the case of a designer opening a ticket and requesting a concise change. It seems like noise to put something like this on the mailing list and effectively force everyone to look at it, and I certainly don't see time savings or any other improvements from this. Rather, we have a ticket to describe the change, tie it to the code changes, and if anyone has further input down the road they can dig up the ticket and see why and where the change was made. > When I first started looking at this project, I was astounded that I > could find hardly any actual code commits in the noise of ticket changes > on the bloodhound-commits@ list -- and at that point ceased to wonder > why not much progress had been made in almost a year. > I would disagree that "not much progress has been made in almost a year", particularly since there were two developers on the project for most of that time. That said, let's always aim to do better and move faster! > This is a bit like the hammer and nail story -- just because you have an > issue tracker doesn't mean every passing thought needs to be recorded in > it. > Sure, not "every passing thought". We seem to disagree significantly on where the line should be drawn. You and Greg seem to tend towards "no thoughts", or at least Greg seems to feel that "no thoughts" should occur on the mailing list, and you seem to suggest "few thoughts". I also see your and Greg's view as being "subversion-centric". As in, why have an issue tracker when you can just do everything in SVN and on the mailing list? Finally, I will just say that I spend a small amount of time interacting with the issue tracker on a typical day, and I feel that I make a lot of commits, but I will continually aim to do better.
