Explicit issue relationships

Events happening in the community are now at Drupal community events on www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

What's your idea?

This is contingent on us remaining on Project* for issue management, but if we move to something else (GitHub, GitLab, Phabricator, etc.) consider this a "I really really wish whatever we move to had this feature" consideration. (I know GitHub does not.)

It is increasingly common for issues to relate to one another. One may block another, one may be a spinoff of another, one may be a planned follow-up, etc.

Drupal.org currently doesn't track that in the slightest. We can manually link to issues with a filter, but there's no automated way to give semantic meaning to "I dropped a link to issue 123 into a comment somewhere". That's really not useful, especially for more complex tasks.

The best solution I've ever seen to this problem is in the Redmine issue tracker (an open source Ruby app). Entirely independent of comments, an issue may have references added that are one of "related to", "blocks", "duplicate of", or "follows". Those relationships are bidirectional, meaning if issue 123 "blocks" issue 456, then issue 456 is automatically "blocked by" issue 123 and displays as such. (Similarly "duplicates" and "preceeds".)

That allows us to very clearly and in a parsable fashion track "this issue can't happen until this other issue, which can't happen without this other issue, but this other issue was a duplicate of it, and this issue is also required but can happen in parallel while the other can't", etc.

What are the benefits?

Even just showing that information explicitly on issue pages would be a massive improvement for large and complex efforts (cough core initiatives cough).

But once we have that metadata in place, we could also generate statistics and visualizations to show just how deep our dependency chains are getting, if there are ways to break them out, if that depth changes over time, etc. It would also allow us to focus work on key blocking issues because we could know with data what those are rather than with assumptions, feel, and guesswork.

What are the risks?

Aside from the possibility that we end up not using it as much as I think we would, I can't see any.

How can we measure the impact of this idea? (metrics)

The number of issues that actually have related issues marked, and the degree to which we leverage that information in planning and decision making.

Who directly benefits from / will use this improvement? (target audiences)

Anyone working on problem spaces that span more than one or two issues. (Eg, most of the Drupal 8 cycle.)

Are additional resources available for discovery/implementation? (volunteer effort, financial backing, etc.)

Prototype implementations of this functionality have been written at least twice; I know mikey_p did one of them. That was a while ago and it would probably have to be written over again for Drupal 7, but there would probably be people able to work on it if they knew it would actually get used this time.

Comments

Actually, this will be part

webchick's picture

Actually, this will be part of the D7 upgrade, it looks like. :) https://drupal.org/node/44162

Win!

Crell's picture

n/t

GitHub DOES have this

Homotechsual's picture

GitHub DOES have this functionality - it shows an XXX referenced this issue post where the issue number is referenced in another issue.

Redmine FTW!

colan's picture

Here's another reason to go with Redmine then. ;)

I'm not sure if Gitlab has this feature as I haven't looked at it too closely yet.

Drupal.org 2014 roadmap brainstorming

Group organizers

Group categories

Difficulty to implement

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: