I feel like between Blocking, Blocks, Mentions, Projects, Project Workboards, editing the Description, and leaving a Comment, there are a good number of options for presenting task relationships. I feel like this has been suggested in the past, but I can't find a task specifically.

@chad: it may be nice to have a coalesced list of all "referenced in the comments" tasks. Right now you need to skim through all the comments or have someone manually edit the description.

well i doooo like automagical stuff.

If it were to be automagic, there should at least be a way to remove related tasks... For example, someone might say This is related to T123 and receive a reply of No, this is a separate issue. In this case, we should be able to remove T123 from the "automagic related tasks" field.

I don't see a need for such a field honestly, at least it doesn't seem to solve any new problem that all the other means of relating tasks together already exist. Asking people to maintain yet another field fundamentally makes the product more complicated to use / understand overall, which in my mind if we're going to make the product more complicated, it needs to be a significant win.

Yeah, it definitely is a weaker relationship than the current "blocking tasks" relationship. FWIW, I think that JIRA has a "related issue" field (I could be wrong, I've never actually used JIRA).

If this is an automated list of mentioned objects displayed in the header, it would likely resolve some or all of T6831: Embedding a mock or a file in a task should add a link in the header.

Related: Phabricator need structured way of relating non-blocking tasks to each other (like Bugzilla's "See also"), showing that relation in both tasks
https://phabricator.wikimedia.org/T76101

See T4207 for task graphs.

Oh, sorry, I completely misread, ignore me.

Although T4207 is sort of related, in that it proposes a new kind of "parent/child" relationship (distinct from "blocks / blocked by").

Another relationship which has come up a couple of times is "followup", e.g. "task X is basically done but there are some loose ends to clean up later on, so provide a 'create followup' button to create a related task".

I generally share @chad's caution about expanding relationship types, though. If we do all of this, we have Blocking/Blocks, Mentions, Projects, Related, Parent/Child, Follower/Follows, which seems like too many relationship types to possibly be useful.

The use cases for "related" feel weaker to me than the use cases for Parent/Child and Follower/Follows, too.

IMHO the "follow-up" task is the same as a "parent" (blocked-on) task: one that needs to be completed after the current one. It's just not exposed conveniently in the UI so nobody really creates parent tasks for follow-ups. That is what I suggested we should surface in T8794.

Tentatively, I'm thinking about doing this (some discussion in T4788, too):

• Turn the new "Task Graph" box into a tabbed content box.
• Put existing "Revisions", "Commits", and "Mocks" into tabs.
  • Eventually, make the "Mocks" tab really fancy with thumbnails.
• Add a "Mentions" tab, listing objects which mention the task.
• Add a "Merged" tab, listing tasks which were merged into the task.

We've renamed "Blocking / Blocked By" to "Parent / Subtask", mostly for clarity, but also to dispel some of the stronger use case connotation that the "Blocking" language had.

I don't currently plan to add a new "related" or "followup" formal status. These are probably fairly easy to add in third-party code now if you have a strong use case for them since the relationship stuff has become modular, but the UI would still likely need to be forked today.

I imagine that between persisting mentions and the more general "Parent / Subtask" language, the use cases for "Related" and "Followup" may be mostly addressed. I haven't seen any particularly strong use cases here or in connection with T10034, and haven't really run into any myself either.

If commits will end up in a tab, are there any plans on changing the link format at the commit list in the details section? It can sometimes become poorly readable since the links consists of repo and revision data prior to the messages.

+1 for mentions, that would serve the same purpose as see also: or related tasks: would. Primarily it would just be nice to be able to see them in one place instead of hiding in comments...

I added "Mentions" (and "Mocks") recently in connection with T4788.

I'm going to leave this open for possibly pursuing "Merged", although I don't plan to do that in the immediate future. I think there's another task floating around somewhere about showing "This task was merged into X" more clearly, and that might be a good time to look at "Merged" more closely.

@epriestley Tasks that are invisible to the user show up in Mentions as "Restricted Task". Is that intentional? In most other places such tasks are simply invisible. It is information leak (even if a very small one) and does not seem to provide any benefit.

I'll strip restricted handles from the "Mentions" lists.

In some cases we show "Restricted <Thing>" because it's potentially unclear/confusing if we don't and showing it makes it more obvious what's happening, which is worth the tiny information leak. An example is that when a user adds tags for restricted projects, we show the action because it may be, e.g. accompanied by a comment which doesn't make sense if you don't see the action, or another user may respond to the action in a way that makes no sense if you can't see what happened.

That is, the comment @alice, why did you do that? makes perfect sense if you see @alice added project tags: Restricted Project, Restricted Project. but is potentially really perplexing if we hide that transaction completely and you can't see that she did anything -- the commenter looks like they're crazy or talking about the wrong task.

In the case of mentions, I don't think there's any opportunity for that sort of confusion, or it's so mild that it's not worth the information leak (and in many cases, particularly with Conpherence mentions, clutter).

We pay a tiny performance penalty to figure out if handles are restricted or not while building the list instead of later, while rendering the page, but we can deal with that if it ever shows up on a performance profile. In the worst case, I think there are some slightly-too-clever things we could do pretty easily if it did. I suspect it's not even on the top 1000 things we could make faster, though.