Distributed Issue Tracking [closed]

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

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 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.

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.

Filed under: softwareengineering - @ 13:54

Thẻ: distributed-computing, issue-tracking, version-control

Thiết kế website giá rẻ

Danh mục

Distributed Issue Tracking [closed]

I am aware of:

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