Yes, you are correct, I want to wildcard the repository names. Thanks for your alternative fixes. The low priority is not a problem.

@pingpongboss, in T11787 it looks like you actually want to wildcard the repository names, not the paths?

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

@rrfeng: You already brought this up in T11680 - please see and follow the reply you received there. No need to add comments in numerous places to decentralize any conversations about the (currently unclear) underlying issue you're perceiving. Please stick to T11680 - thanks!

I think the "graph trace" UI is not suitable for task graph.
The most scene which has problem is 1 task has too many sub tasks. And then the graph-status takes too much spaces of the page(It is so wide).

@ksmith it's a Python script that you would run on your local machine. If you have arcanist setup for development it should be pretty simple to get it working. Ideally it would just be a plugin, but I didn't look into that approach yet.

@lyahdav : That looks pretty cool. It's not quite clear to me where it runs. Is this a script that one would install on the same box that phab itself is running on?

For anyone trying to get Kanban statistics / reports in the meantime, you can try this project I recently started working on:
https://github.com/lyahdav/analytics-limn-analytics-data/tree/kanban_stats. It generates a CFD (Cumulative Flow Diagram) and computes cycle time and lead time.

This stuff is defined in PhabricatorUser->loadEditorLink(), which ain't great but probably not worth generalizing.

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.

@epriestley Is there a pathway for reading (not writing) edges which would be open to community contribution? Having arc patch Tnnnn functionality, pulling all the revisions attached to a particular task, would be really attractive for us as we tend to have a larger number of revisions per task.

See Planning for help understanding timelines and priorities.

Is this still actively being worked on, is there a different solution than View Options->Set Tab Width, or should I apply the patch referenced by raman.rathod?

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

See T4788#184477 for current plans.

In T4788#185925, @CodeMouse92 wrote:

[...] Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations [...]

I definitely agree that in most cases, 100+ subtasks (especially direct subtasks) is better as a project. Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations if there is an exception that hasn't been thought of.

It might be useful if the dependency resolution was only two-levels deep. That wouldn't really solve the problem for extremely wide trees though.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

Also, before that is done, rather than showing "Task graph too large to display ..." message, have fallback to the old plain list of tasks. Therefore the information will still be available, but just simply not provided as fancy...

Re the limiting to hardcoded 100 nodes without any criteria:

The best of the best is of course our https://phabricator.wikimedia.org/T4007 ;-)

In T4788#185751, @bd808 wrote:

The task graph can get a bit out of hand -- https://phabricator.wikimedia.org/T2001

In T4788#184537, @epriestley wrote:

so the UI should still look good given that edge-case.

Understanding the use case is important in choosing how the UI degrades.

@epriestley, just thought you'd like to know that, on that aforementioned massive task, the task names are now entirely missing. If you scroll all the way to the right, it shows the assigned person, and that's it. :\

@epriestley, I'm not expecting any particular solution, just as long as the list of subtasks is navigable in some sane fashion.

so the UI should still look good given that edge-case.

Although the new graph display has the branch-like display at the left, that column is removed from the task titles (2 columns away) - which aren't indented to clearly show the parent-child relationship.

@epriestley, the use case is actually from my content development department. It's hard to explain the task, but the hundreds of direct subtasks was unavoidable, and the project workboard did not work well in their workflow. Developing content for educational software can be extremely demanding. That said, I'll admit it isn't common to have hundreds of subtasks. Still, it is a scenario that can happen, so the UI should still look good given that edge-case.

I'm leaning toward making it a "Relationships" box with "Task Graph", "Mocks" (with a thumbnail/gallery view instead of just titles), and "Commits/Revisions" (probably with a little more status information than we currently show).

That would be perfect!

One possible solution might be to make "Task Graph" box "Task Dependecies" and have a separate tab for a straight list (default, parent/sibling only) and graph.

Just FYI, but on this install there's some weird rendering going on:

I'm moving this to "Rugged Terrain", as the best available pathway forward leaves us with dramatically higher implementation cost than the reasonable value of the feature. We can pursue this after tasks with better aligned costs and value are addressed.

Current task graph is great for visual representation... but can we get somewhere very simple list of blocks/blocked by?

T2637 cycles down to itself again

A few tasks (like T2637) are still drawing crazily enormous trees. I think our tasks are especially highly-connected and 97% of what I've looked at seems reasonable, so this might not be much of an issue for other installs, but I think we definitely need some kind of behavior where we hide the more distant parts of the tree once it gets too big.

I guess that after some exposure, it would be clear; If we're prioritizing experienced users over new ones, it's fine the way it is.

It's clear enough to me that higher -> more parental. It might be nice to make T123 not a link and bold, like elsewhere, for easy copy-pasta.

Not a good idea, but an idea:

After looking through real-life applications, this now seems obvious and in @avivey example A is Parent of B. At first glance - there's relation. But yeah, arrows would help, only thing problematic is agreeing on arrow notation.

@avivey Do you have any ideas on how to make that more clear? I'm imagining it will probably be obvious on real data when you know what the tasks are and you'll get used to it pretty quickly, but maybe not.

in first glance, I'm not sure if A depends on B or the other way around:

Now it looks pretty and actually first glance tells something :)

Seems kinda good now? Could maybe use some style/layout tweaks on the table (I'd like resolved tasks to be more obvious, for example), but that graph seems like it's actually pretty good/useful to me at first glance. Need to poke around more.

wut

Woooo pretty pictures graph! Can't say I can deduct any task relationship from graph, but nevertheless, it's very pretty!

Looks like I didn't think that one through very well.

I'm pretty tempted to try using the "graph trace" interface to show task graphs. My major concern is that it task dependency graphs tend to be fairly wide and shallow (one task has many dependencies) while commit/revision graphs tend to be narrow and deep (long chains of dependencies). The element isn't as good at showing wide, shallow graphs. If a task has ten subtasks, we'll get a graph like this: