8

Distributed issue tracking seems like a belting idea to me, but it has never really taken off in a big way. Is there a good reason for that?

I am aware of:

  • bugz everywhere
    • too complex to set up
    • too many requirements
    • reasonably successful, used by some large projects
  • fossil
    • tries to integrate too many things, and ends up being a slightly worse version of all of them - except maybe for the distributed issue tracking part, which is decent (probably best I have seen)
  • several other smaller projects
    • none of which have gained any traction

I am thinking about making my own, but before I begin, I would like to know why none of the others have taken off in a big way.

Anticipated issues: (I think they can all be overcome)

  • merging distributed issues as they are updated is complex, as is merging any code files
  • conversation continuity can be destroyed, as comments can come in at any time, perhaps not in the correct flow
  • expectation of central server with issues up-to-date
Billy Moon
  • 329
  • 2
  • 5
  • 14
  • 6
    My 2c is that distributed issue tracking don't make a whole lot of sense in many ways -- the point of issue tracking is to keep everyone on the same page so centralized is good. If I wanted distributed I'd just use evernote. – Wyatt Barnett Mar 29 '13 at 21:10
  • @WyattBarnett that is a valid concern, perhaps mitigated by behavioural patterns, and perhaps software. Personally I see the only difference between a blog and a website is how often you update it, is it not the same for distributed issue tracking? If you update it often, it is the same as checking a web-page of issues often no? The only danger is people not updating, and submitting issue often, but so long as there is a one-click solution, it is not a problem right? I understand that this need for connectivity is in conflict with one of the large benefits of `distributed` issue tracking. – Billy Moon Mar 29 '13 at 21:16
  • Not submitting issues is the #1 issue I've seen in bug trackers. As @JeffO points out having some offline capabilities is vastly more important than having a distributed system. In the same way git is nice but github really makes git worthwhile. – Wyatt Barnett Mar 29 '13 at 23:29
  • 1
    @WyattBarnett it is hard to speculate how people would react to a well formed tool. Perhaps they would be more likely to submit issues if it were possible to do offline, and without connection/explicitly logging in. Perhaps people who submit issues online would end up delaying their postings if it was available offline. My intuition, is that if it is made extremely simple to push, people will do it frequently, because if they have created an issue, they will want the world to see it. – Billy Moon Mar 29 '13 at 23:37
  • How will a manager handle two different project with some over-lap of team members? They're going to want some sort of firm wide reporting capability. – JeffO Apr 11 '13 at 01:48

3 Answers3

13

Just because source control + distributed was a huge success, issue tracking + distributed isn't necessarily a good idea.

What do we gain from distributed source control and would it apply to issue tracking?

Easy branching and merging: not really. Actually it is crucial that everybody is on the same page. So branching would be highly undesirable.

Performance: the amount of data transmitted by an issue tracker is rather small, and all the heavy lifting is done on the server, so this isn't an issue.

Advanced workflows (push, pull, staging etc.): issue trackers already have good (and often highly configurable) workflows. So we don't need a distributed system for that. Quite the contrary, it would make things much more difficult, as you have to deal with conflicting changes.

Offline capabilities: sure, these would be nice. However, these can also be had without going fully distributed.

Furthermore, (distributed) source control is used almost exclusively by programmers. Issue tracking is also used by testers, designers, technical writers, managers, marketing, and sometimes even end users. These less people without a computer science background might have difficulties to understand the intricacies of a distributed system.

oefe
  • 951
  • 7
  • 11
  • I imagine the distributed issue tracking to work as a server too, in the same way as git. I would expect developers to use it, with their local (potentially offline sometimes) setup, and other people to use it from the central server only. Do you think that mitigates some of your concerns? – Billy Moon Apr 07 '13 at 09:33
  • I don't think merge conflicts will be a big issue, as each new entry in an issue will be accompanied by a timestamp, so merge conflicts should be easily resolved (automatically by the program) by using these time stamps. I don't expect existing content to be changed much. Do you think this is realistic? – Billy Moon Apr 07 '13 at 09:37
  • Do other people use issue tracking before there is a repo to share code - or before the repo is used to track code? – Billy Moon Apr 07 '13 at 09:38
  • I imagine for small projects/consultancy work it would be very useful to be able to add issue tracking to the project in a distributed way. It then becomes part of the project archive automatically, and also makes it easy to have some form of issue tracking in place, without managing it as a separate entity. Do you see this as a potential benefit? – Billy Moon Apr 07 '13 at 09:40
  • Tight integration with the VCS, would allow the issue tracker to be easily kept up-to-date. If I code something whilst offline, I can have the integrated issue tracker updated - perhaps closing an issue - and later when I am connected again, I push all the changes to the code, and issues together. Do you think this is realistic/problematic/useful? – Billy Moon Apr 07 '13 at 09:45
  • Apart from adding comments, almost all changes on an issue will change some field, so that conflicts are very likely. And what should happen if two people perform conflicting workflow transitions on separate copies of the issue tracker? How would you merge that? – oefe Apr 07 '13 at 14:55
  • I know teams that use issue trackers without ever wanting too use a source code repository, for example to track hardware change requests. – oefe Apr 07 '13 at 14:57
  • Don't issue trackers and source code control systems already support good enough integration? And source code hosting sites usually offer you issue tracking for each repository that you create. – oefe Apr 07 '13 at 15:02
  • I think that the integration is good, but requires connectivity. I like the idea of working on several things, one after the other offline, then uploading it all together. Also, I like the idea that the issue tracker is easily extensible, so individuals could have plugins just for themselves, like specialised reporting, that is not shared with the group whom it might be irrelevant for. This is made easier, if the issue tracking software can run locally in the user's computer. – Billy Moon Apr 07 '13 at 15:52
  • I expect the field changes to be part of the header of a comment, and not change the existing fields. When an issue is parsed, the newer changes will overwrite the older ones, so the reporting will handle up-to-date meta data, but the recording just puts it all in sequence, like telling a story in chronological order. – Billy Moon Apr 07 '13 at 15:53
  • This doesn't solve the logical problem of conflicting changes. – oefe Apr 07 '13 at 20:34
4

I don't think being decentralized is as important as having off-line capabilities. Integration with source control is a big benefit, so you want each user to be able to conveniently handle both tasks. The closer together they do it the more continuity you'll have.

Even the most distributed teams should be able to put together a web server and tracking system. It would be more beneficial to have a central bug tracker since every user only needs a subset of the bug database. Bugs are usually assigned to someone who can work on it individually. There's nothing wrong with being unavailable to everyone else if it uses some sort of "check-out" system that leaves it in a read only state. A website also allows clients/users to enter and view their own tickets.

You're on to something with the off-line need, but many of the problems you addressed could be avoided with just checking out parts of the bug-tracker to work on while disconnected.

For many users, one of the best integration tools is email especially when you have people outside the team. I'm not going to go back to your website to see if my issue has been resolved. I want an email with a possible reply link to provide feedback. Any developer who responds to a change request email, can send a reply and have it tracked in the system.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • To me it makes most sense to include the issues in the project VCS, so that all issues are available, and it is a problem of reporting to extract the relevant ones. I think the overhead on the repo is acceptable, what do you think? As for a central server, I imagine a system after git, where it is in it's implementation, totally distributed, but you are free to host it on a server you call the central one (like github for example). Any thoughts? – Billy Moon Mar 29 '13 at 22:40
  • The active issues are the relevant ones. Not sure how far back in history I would want my local bug database to go. I'm with you on the central one similar to github. I just think of the bug-tracking portion as more of a todo list that is linked to the code and not a copy of the entire database. – JeffO Mar 29 '13 at 23:06
  • is that concern rooted in the problem of sifting through irrelevant data? or from the point of view of storage space? – Billy Moon Mar 29 '13 at 23:34
  • @BillyMoon - I don't think storage is as much of a problem as the time to synch everyone's tracking entries. It may not be a big deal, but I'm still putting it in the context of distributed call tracking vs. just making an entry to a website. – JeffO Apr 11 '13 at 01:42
2

I'm going to be real specific about actual products. Some will probably like this and others perhaps not, but here goes:

I've used a bunch of tools over the years for issue, task and project tracking. Microsoft Project, Trello and Jira have all had their place.

Now I use Pivotal Tracker. I love it's sophistication yet simplicity of use and I really like the way that as other people edit and update tickets those changes get made and highlighted in your window too, so its far and away the best 'network' style of these tools that I've tried.

Not totally sure if that's what you mean by distributed, but there you go.

If it is, I would get used to and then look at the deficiencies of Pivotal Tracker (if any) for you before developing an alternative.

Michael Durrant
  • 13,101
  • 5
  • 34
  • 60