The more astute of you out there may have noticed in the previous post that there was a brief bit of text explaining that you could link to other issues by simply typing “#123”, or whatever the issue number is. 1 Then, when the comment is displayed, “#123” is displayed as a simple hyperlink to the issue. 2

I spent a significant amount of time trying to determine just how I’d go about enabling people to establish relationships between issues. Generally, you want to consolidate duplicates, make notes of issues dependencies, or just simply reference another issue in conversation. While there are some benefits to creating more explicit relationships between issues, I decided that it wasn’t worth the additional overhead.

The comment form with a short sentence of explanatory text that typing #123 will create a link to issue number 123.
1 Instead of creating an elaborate process for creating relationships between issues, you can simply type the number sign followed by the number of the issue, and system automatically creates a hyperlink when the comment is displayed.

Most of my initial ideas would have required additional tables in the database and a good amount of extra code and business logic. Then, I’d still have to display, manage, and explain those relationships somewhere. That just wasn’t going to work for me. I decided that any additional context about the related issue could just go right in the comments, and that was that.

A screenshot of a hyperlinked issue number.
2 The system automatically creates hyperlinks out of issue numbers as the simple solution for creating relationships.

By creating such a simple solution, I was able to keep the focus on the conversation and avoid a whole mess of code that really wasn’t necessary. Some of you may have concerns that this doesn’t enable an automated way to help determine which issues are higher priority than other issues, and that’s true. However, in my mind, that starts to encroach on the job of the priority field.

Issues will all have their own priority field, and if a blocker is a significant problem, then that’s a separate discussion, and its priority needs to be updated. This keeps things clear and concise. A place for everything and everything in its place.

The only catch here is that the person responsible for the blocking issue won’t be implicitly or automatically be notified of new dependencies. However, when you think about it a bit more, that’s not really a bad thing at all.

I feel strongly that personal accountability and responsibility are critical design considerations for this tracker, and I think it’s perfectly reasonable to expect the assignee of the blocked issue to discuss it with the assignee of the blocking issue in person. That could be over instant messenger, the phone, or even face to face. Regardless, it’s more likely that a normal conversation will help get things moving sooner than two people were commenting back and forth on an issue in an issue tracker.

Related articles… Never miss new articles…

Receive our blog posts in a consolidated monthly email. Don't worry, we hate spam too and make it easy to unsubscribe.

Alternatively, you can subscribe to our blog feed or follow us on Twitter at @sifterapp.