There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

5

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 BarnettMar 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 MoonMar 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 BarnettMar 29 '13 at 23:29

@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 MoonMar 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.
–
JeffOApr 11 '13 at 1:48

3 Answers
3

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.

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 MoonApr 7 '13 at 9: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 MoonApr 7 '13 at 9: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 MoonApr 7 '13 at 9: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 MoonApr 7 '13 at 9: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 MoonApr 7 '13 at 9:45

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.

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 MoonMar 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.
–
JeffOMar 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 MoonMar 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.
–
JeffOApr 11 '13 at 1:42

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.