Ever since I started using a DSCM I've been annoyed with how bad traditional bug/issue/task/ticket/whatever tracking fits into the picture, the biggest one being how there's only one path, not much unlike SVN.
I really want to add a tracker to Gitorious.org, not only because I'm starting to need one myself (and thus I'm guessing it'll be useful for others), but also because I think we have the opportunity to build something that fits better into the world of DSCMs like git. So in the spirit of keeping things open, here's a braindump of my current ideas.
The most basic requirement I have is that I should be able to track tickets across clones and projects. It's a sweet way to collaborate because a bug in "clone-a" could be marked as fixed in "clone-b" (by another user), so instead of messing around with patch files I could just pull in his changes and have the bug fixed. This is pretty much exactly the way we all use git today, it's just not tied in properly with bug reports.
It should also tie into the growing ecosystem of gitorious itself, lets say I have a failing testcase and someone files a ticket on it, but after looking at it it turns out it's a bug in rspec, the testing framework, and I could just "move" that ticket to the rspec project. But still have it tracked in my project, so that whenever it's fixed in rspec, the bug would be marked as "fixed upstream" or something.
It would also be really neat if the tracker itself was distributed, so I at least could bring it along on the train/bus/airplane and resync when I'm back online. It may turn out to be a pipe dream, but I'm looking at a couple of document databases with replication features that I think would be a good possible solution. To be honest, it kinda makes the most sense to store the bugs directly in the repository, with a nice web UI on top for those into that, since it would make it easier to track them across clones and branches, but that might be a tad intruding for some projects?
While it potentially increases the complexity of gitorious a bit, I really do think it'll be a nice feature for the projects that wishes to use it (eg opt-in). Mostly because it's a good aid in helping to build a community around the given project; new people can easily pick out something to work on their clone, and regular contributors gets all the usual benefits of a bug tracker.
But what do you guys/girls think? I'm thinking that at least the first one of the above is a killer, and something I'd love to have on my internal/company projects...
That is an awesome idea! Great minds must think alike, because I've been thinking it'd be sweet to have a distributed ticketing system as well since I started using Git :)
I agree - the easiest way to implement this would be just to put the tickets in text files, which are versioned by git.
Git handles symlinks, so all the tickets could be placed in a "tickets" folder, then all of the statuses could symlink to the ticket.
> Ever since I started using a DSCM I've been annoyed with how bad > traditional bug/issue/task/ticket/whatever tracking fits into the > picture, the biggest one being how there's only one path, not much > unlike SVN.
> I really want to add a tracker to Gitorious.org, not only because I'm > starting to need one myself (and thus I'm guessing it'll be useful for > others), but also because I think we have the opportunity to build > something that fits better into the world of DSCMs like git. So in the > spirit of keeping things open, here's a braindump of my current ideas.
> The most basic requirement I have is that I should be able to track > tickets across clones and projects. It's a sweet way to collaborate > because a bug in "clone-a" could be marked as fixed in "clone-b" (by > another user), so instead of messing around with patch files I could > just pull in his changes and have the bug fixed. This is pretty much > exactly the way we all use git today, it's just not tied in properly > with bug reports.
> It should also tie into the growing ecosystem of gitorious itself, > lets say I have a failing testcase and someone files a ticket on it, > but after looking at it it turns out it's a bug in rspec, the testing > framework, and I could just "move" that ticket to the rspec project. > But still have it tracked in my project, so that whenever it's fixed > in rspec, the bug would be marked as "fixed upstream" or something.
> It would also be really neat if the tracker itself was distributed, so > I at least could bring it along on the train/bus/airplane and resync > when I'm back online. It may turn out to be a pipe dream, but I'm > looking at a couple of document databases with replication features > that I think would be a good possible solution. > To be honest, it kinda makes the most sense to store the bugs directly > in the repository, with a nice web UI on top for those into that, > since it would make it easier to track them across clones and > branches, but that might be a tad intruding for some projects?
> While it potentially increases the complexity of gitorious a bit, I > really do think it'll be a nice feature for the projects that wishes > to use it (eg opt-in). Mostly because it's a good aid in helping to > build a community around the given project; new people can easily pick > out something to work on their clone, and regular contributors gets > all the usual benefits of a bug tracker.
> But what do you guys/girls think? I'm thinking that at least the first > one of the above is a killer, and something I'd love to have on my > internal/company projects...
> But what do you guys/girls think? I'm thinking that at least the first > one of the above is a killer, and something I'd love to have on my > internal/company projects...
> It would also be really neat if the tracker itself was distributed, so > I at least could bring it along on the train/bus/airplane and resync > when I'm back online. It may turn out to be a pipe dream, but I'm > looking at a couple of document databases with replication features > that I think would be a good possible solution. > To be honest, it kinda makes the most sense to store the bugs directly > in the repository, with a nice web UI on top for those into that, > since it would make it easier to track them across clones and > branches, but that might be a tad intruding for some projects? > Have you seen Bugs Everywhere? (http://bugseverywhere.org) It > currently offers git support, stores bugs in the repository, etc. I > would guess that integrating it with Gitorious would be relatively > straight-forward--either parse the files in the .be directory > directly, or snarf them into models post-commit, saving changes made > in the web interface and pushing those changes into the repository. > This might even support your "move a bug" scenario by dumping the > bug into the target repository via BE.
But I could see how that might be intrusive. Maybe moving a bug is just like a pull request? Tell me that you've created a bug in your project that might be a bug in mine, but give me the opportunity to review the bug before it gets moved and committed automatically.
On Wed, Mar 5, 2008 at 11:25 PM, Johan Sørensen <jo...@johansorensen.com> wrote:
> Greetings,
> Ever since I started using a DSCM I've been annoyed with how bad > traditional bug/issue/task/ticket/whatever tracking fits into the > picture, the biggest one being how there's only one path, not much > unlike SVN.
> I really want to add a tracker to Gitorious.org, not only because I'm > starting to need one myself (and thus I'm guessing it'll be useful for > others), but also because I think we have the opportunity to build > something that fits better into the world of DSCMs like git. So in the > spirit of keeping things open, here's a braindump of my current ideas.
> The most basic requirement I have is that I should be able to track > tickets across clones and projects. It's a sweet way to collaborate > because a bug in "clone-a" could be marked as fixed in "clone-b" (by > another user), so instead of messing around with patch files I could > just pull in his changes and have the bug fixed. This is pretty much > exactly the way we all use git today, it's just not tied in properly > with bug reports.
> It should also tie into the growing ecosystem of gitorious itself, > lets say I have a failing testcase and someone files a ticket on it, > but after looking at it it turns out it's a bug in rspec, the testing > framework, and I could just "move" that ticket to the rspec project. > But still have it tracked in my project, so that whenever it's fixed > in rspec, the bug would be marked as "fixed upstream" or something.
> It would also be really neat if the tracker itself was distributed, so > I at least could bring it along on the train/bus/airplane and resync > when I'm back online. It may turn out to be a pipe dream, but I'm > looking at a couple of document databases with replication features > that I think would be a good possible solution. > To be honest, it kinda makes the most sense to store the bugs directly > in the repository, with a nice web UI on top for those into that, > since it would make it easier to track them across clones and > branches, but that might be a tad intruding for some projects?
What a coincidence! I have been thinking about a very similar thing lately. Let me elaborate.
A couple of years ago, while I was working in ThoughtWorks, I learned all the voodoo of XP and Scrum - especially how useful burndown/burnup charts and tracking velocity is. TW uses it on all their projects, and we do the same in BEKK. The most important tool here is a big whiteboard with index cards. Each index card is a story or a task, and it moves from left to right as it travels from the states unprioritised, prioritised, in progress, ready for qa and finally to done done done (the states vary from project to project). Burndown and Velocity is measured by looking at how much gets done in a fixed amount of time (usually a week or two). Burndown and Velocity are then used throughout the project to provide better and better predictions of how much can be done by what time.
Okay.
Using a wall, paper and excel for the burndown works great in most cases. But for distributed (open source) or big projects there is often a need for a tool. With a tool you often lose the tangible visibility there is on a wall, but still - we're not always in the same room.
With all the existing tools for Agile project tracking being too heavy and expensive, I sat down and hacked together my first version of Kipling (my first Rails app). This was my first Rails app, it was before Scriptaculous, so I stole Google's javascripts for their portal thingie. I managed to get something running that resembled a reall wall of cards, where you could drag the cards around and have them written to a database.
With that done it was time to tackle the next challenge. History. I needed to keep track of where each card had been at what time in order to derive these wonderful burndowns and other metrics. Long story short, I've rewritten this 4-5 times, using acts-as-versioned, acts-as-versioned-with-relations (or something), subversion (I think you saw that Johan) and a File DB. I have failed every time.
Storing stories and tasks in Subversion actually came closest, I had mostly technical problems here. I haven't done much about this in a while. ThoughtWorks has released Mingle, which is really cool, but it doesn't tie in with your SCM as Johan describes.
I definitely think the SCM is the way to go. That's where bugs, RFEs, stories, tasks etc should live. I think a Wiki-style format with some structure is the way to go here. Example:
h2. Make the socket close automatically The socket should be closed automatically after 3 seconds. It doesn't do so currently because bla bla bla. --- tags: @sockets @in_progress @iteration_4 point_estimate: 5
This is a little inspired from Taskpaper - a plain text based GTD tool. I actually set up a new Gitorious repo for my umpteenth attempt to get this right: http://gitorious.org/projects/kipling (nothing here yet though)
> While it potentially increases the complexity of gitorious a bit, I > really do think it'll be a nice feature for the projects that wishes > to use it (eg opt-in). Mostly because it's a good aid in helping to > build a community around the given project; new people can easily pick > out something to work on their clone, and regular contributors gets > all the usual benefits of a bug tracker.
> But what do you guys/girls think? I'm thinking that at least the first > one of the above is a killer, and something I'd love to have on my > internal/company projects...
I would try to keep it decoupled (but interoperable) from Gitorius if possible. And possibly from Git too. An SCM based issue tracker is a novel idea, and if we can make something that would work in many SCMs it could potentially attract a lot of contributors and become a really nice product.
I am definitely interested in contributing to this.
On Mar 5, 2:25 pm, "Johan Sørensen" <jo...@johansorensen.com> wrote:
> But what do you guys/girls think? I'm thinking that at least the first
> one of the above is a killer, and something I'd love to have on my
> internal/company projects...
I'd love something like it. I've been thinking along the same lines,
wondering just how such a thing would work.
On Thu, Mar 6, 2008 at 9:44 AM, aslak hellesoy <aslak.helle...@gmail.com> wrote: > With that done it was time to tackle the next challenge. History. I > needed to keep track of where each card had been at what time in order > to derive these wonderful burndowns and other metrics. Long story > short, I've rewritten this 4-5 times, using acts-as-versioned, > acts-as-versioned-with-relations (or something), subversion (I think > you saw that Johan) and a File DB. I have failed every time.
> Storing stories and tasks in Subversion actually came closest, I had > mostly technical problems here. I haven't done much about this in a > while. ThoughtWorks has released Mingle, which is really cool, but it > doesn't tie in with your SCM as Johan describes.
> I definitely think the SCM is the way to go. That's where bugs, RFEs, > stories, tasks etc should live. I think a Wiki-style format with some > structure is the way to go here.
I'm not so sure it really needs to actually _be_ in the SCM anymore. As long as I could edit it with my $EDITOR I think I'll be happy.
I began on a prototype implementation yesterday using Yurii's StrokeDB (http://gitorious.org/projects/strokedb). The reason I went for that rather than directly in git, is so that I can dictate the structure a bit more and gear it towards tickets, instead of just content in general. It'll also mean we can potentially implement our own merge strategies. It's also in pure ruby (at least for now) and I know Yurii's goals for it fits in pefectly with ours. And unlike CouchDB, it's easily embedable, meaning a console interface, web interface and a rubycocoa interface is very feasible without requiring special daemons to be running.
So basically, the goal of the prototype is to implement a generic structure for tickets and whatever data thats associated with them, along with a commandline interface. And hopefully also syncing/replication between ticket databases.
So the idea is to have it in the git repository dir, but .gitignore'd and controlled with a separate binary, autoclosing/commenting in commit messages would be done via a git hook. And by having the "ticket database" in the git dir allows us to query the git-repository from the ticket system, rather than the other way around.
> I would try to keep it decoupled (but interoperable) from Gitorius if > possible. And possibly from Git too. An SCM based issue tracker is a > novel idea, and if we can make something that would work in many SCMs > it could potentially attract a lot of contributors and become a really > nice product.
It would be fairly decoupled by default, since it wouldn't base its storage mechanism on any SCM features. However, my biggest concern is that this distributed ticketing system would end up being too exotic for most people, but then again, so where things like Git for most people not long ago (though I'd argue it still is for the masses ;)). But I think a good webinterface that acts almost like they're used to in other systems will go a long way, along with a powerful distribution model for those who want/need it.
And I've looked at DITrack, DisTract and BugsEveryone, but the most common problem is that they're either too closely tied with a SCM I don't use, or the fail to give me the overview a bugtracker should be able to give me. But most importantly, I'm interested in exploring this topic fully myself (and anyone wanting to join in), and with gitorious.org in mind.
> I am definitely interested in contributing to this.
On Mon, Mar 10, 2008 at 1:19 PM, Johan Sørensen <jo...@johansorensen.com> wrote:
> On Thu, Mar 6, 2008 at 9:44 AM, aslak hellesoy <aslak.helle...@gmail.com> wrote:
> > With that done it was time to tackle the next challenge. History. I > > needed to keep track of where each card had been at what time in order > > to derive these wonderful burndowns and other metrics. Long story > > short, I've rewritten this 4-5 times, using acts-as-versioned, > > acts-as-versioned-with-relations (or something), subversion (I think > > you saw that Johan) and a File DB. I have failed every time.
> > Storing stories and tasks in Subversion actually came closest, I had > > mostly technical problems here. I haven't done much about this in a > > while. ThoughtWorks has released Mingle, which is really cool, but it > > doesn't tie in with your SCM as Johan describes.
> > I definitely think the SCM is the way to go. That's where bugs, RFEs, > > stories, tasks etc should live. I think a Wiki-style format with some > > structure is the way to go here.
> I'm not so sure it really needs to actually _be_ in the SCM anymore. > As long as I could edit it with my $EDITOR I think I'll be happy.
> I began on a prototype implementation yesterday using Yurii's StrokeDB > (http://gitorious.org/projects/strokedb). The reason I went for that > rather than directly in git, is so that I can dictate the structure a > bit more and gear it towards tickets, instead of just content in > general. It'll also mean we can potentially implement our own merge > strategies. It's also in pure ruby (at least for now) and I know > Yurii's goals for it fits in pefectly with ours. And unlike CouchDB, > it's easily embedable, meaning a console interface, web interface and > a rubycocoa interface is very feasible without requiring special > daemons to be running.
> So basically, the goal of the prototype is to implement a generic > structure for tickets and whatever data thats associated with them, > along with a commandline interface. And hopefully also > syncing/replication between ticket databases.
> So the idea is to have it in the git repository dir, but .gitignore'd > and controlled with a separate binary, autoclosing/commenting in > commit messages would be done via a git hook. And by having the > "ticket database" in the git dir allows us to query the git-repository > from the ticket system, rather than the other way around.
> > I would try to keep it decoupled (but interoperable) from Gitorius if > > possible. And possibly from Git too. An SCM based issue tracker is a > > novel idea, and if we can make something that would work in many SCMs > > it could potentially attract a lot of contributors and become a really > > nice product.
> It would be fairly decoupled by default, since it wouldn't base its > storage mechanism on any SCM features. However, my biggest concern is > that this distributed ticketing system would end up being too exotic > for most people, but then again, so where things like Git for most > people not long ago (though I'd argue it still is for the masses ;)). > But I think a good webinterface that acts almost like they're used to > in other systems will go a long way, along with a powerful > distribution model for those who want/need it.
> And I've looked at DITrack, DisTract and BugsEveryone, but the most > common problem is that they're either too closely tied with a SCM I > don't use, or the fail to give me the overview a bugtracker should be > able to give me. But most importantly, I'm interested in exploring > this topic fully myself (and anyone wanting to join in), and with > gitorious.org in mind.
> > I am definitely interested in contributing to this.
> Still interested? ;)
I have started to hack on my own thing (Kipling - just haven't pushed yet). I'll see where it leads and keep an eye on your work. I think we may have somewhat different goals. But we'll see.
