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.

I'm just going to close this:

@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. :\

I'm going to close this in favor of more specific followup subtasks:

@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:

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:

There is now a Edit Related Tasks → Close as Duplicate action next to the existing Edit Related Tasks → Merge Duplicates In action in the related tasks submenu. This change is live on this install:

This install now exposes two separate actions in a new submenu, although the backend is only sort of halfway converted. My plan is:

I'd like to have a clearer sense of how we're planning to resolve T10034 before moving forward here, even if we don't actually build any of it yet. Briefly, I think some of the problems here are:

I believe this is resolved and accounted for, let us know if anyone is hitting issues.

In T11126#179873, @eadler wrote:

Silly question but can't we use CSP Level 2's referrer directive (https://www.w3.org/TR/CSP11/#directive-referrer) to avoid leaking information without the need to build full image proxying?
If that doesn't work can we use <iframe seamless referrerpolicy="no-referrer"> ?

Silly question but can't we use CSP Level 2's referrer directive (https://www.w3.org/TR/CSP11/#directive-referrer) to avoid leaking information without the need to build full image proxying?
If that doesn't work can we use <iframe seamless referrerpolicy="no-referrer"> ?

Looks like there's a JSON API: https://xkcd.com/json.html

My primary concern here is that I strongly dislike adding options to the product

This is in master and live on this install. Let me know if you hit issues with it, especially on mobile. Seems fine on my iPhone 4 but I don't have a ton of devices on hand for testing.

quick note: even on systems with 'normal' windowing systems many users
dislike or can't use drag-and-drop workflows. I'm mostly mentioning this so
that the non-D&D workflow isn't entirely treated as a second class citizen.

D15953 played out more or less as described above. I'm not going to land it before cutting stable this week since it touches Workflow in a couple of ways that might have unforseen consequences, but I expect it to be available in master some time later tonight or tomorrow.

After D12066, we have an upload workflow which gracefully accommodates very large files (progress bars, resumable uploads, no server host needs to handle more than 4MB of data on disk or in memory at once). This flow is activated when you drag-and-drop, and we've successfully used it to transfer reasonably-sized cluster import/export files (1-2GB) for the better part of a year now.

In T5187#175015, @epriestley wrote:

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

See Paid Prioritization and L34 Phacility Prioritization Service Agreement for specifics, if you haven't run across them yet.

You're behind T10917 and T10939 in the queue (see the Prioritized workboard) and some other things which are wrapping up, so it will probably be about a week before we can pursue this. If that sounds reasonable, we can get this into the queue now and confirm with you before starting work.

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

@epriestley I'm happy to try to pay you to review the patch if that'll help.

(If that answer isn't particularly satisfying, maybe see discussion starting here: T7820#172877.)

We haven't seen much interest in this from outside WMF, so there are probably several hundred tasks ahead of it on our natural roadmap.

This is still a big problem for Wikimedia's Phabricator installation, making it unnecessarily difficult to file or amend bug reports about mobile issues.