For prioritization, I estimate we can complete this within 6 hours. It may all be straightforward and easier than that, but there are enough weird edge cases and UI implications that I don't want to commit to a best-case estimate.

As you described, the model would be very complex considering a task can be in more than one subprojects, or a milestone. Why is it needed to have separate columns for subprojects in a parent project's workboard?

It would be simpler to include in the workboard of a parent project all the tasks of the subprojects (and their subprojects), without showing any extra column. It would allow the parent project workboard to keep the focus on milestones (or whatever columns it has set), with the possibility to focus on a specific subproject (with its own workboard if needed).

To give more info about our use-case: We use a parent project and a few direct subprojects to track the area in which a task is (for example: Newcomers, Mac OS X, Proxy editing, etc). The feeling now is that by assigning a task to a subproject it "dissapears", since it cannot be tracked in the workboard with milestones of the parent project, and is two extra clicks away: Subprojects > Mac OS X. Sometimes we want to see only the Mac OS X related tasks, but they are still part of the parent project and they should be displayed along with the others to be able to include them into milestones.

Thanks for considering, and sorry if this has been discussed already or is clearly not what you want.

The feeling now is that by assigning a task to a subproject it "dissapears", since it cannot be tracked in the workboard with milestones of the parent project, and is two extra clicks away: Subprojects > Mac OS X.

We had these exact same considerations regarding subprojects, and the "disappearing" is particularly annoying.

It would be simpler to include in the workboard of a parent project all the tasks of the subprojects (and their subprojects), without showing any extra column.

This was what we'd like to use parent projects for, too. But then it hit us that the tagging functionality actually does exactly this, completely without subprojects. Just tag the task in question with both the "parent" project and the perceived "child" (this without actually using subprojects at all of course, since they make this impossible), and voilà, you have it both in the parent workboard for a quick overall view, and in all so-called child project workboard(s) for more detailed view. What's more, the tag listing inside the task already shows the workboard column for each tag/project, so detailed status tracking is easy.

Now, this is actually exactly what I want from "subprojects", and my current view is basically that the official subprojects implementation only makes this much more clunky and restricts some parts of it, rather than moves it forward. As it is, the current subproject implementation doesn't seem to do much else than make a couple of links appear, and restrict the usage of some features (tagging and project membership handling are changed/restricted, at least).

The proposed behavior (no subproject columns) means that tasks could be in multiple different columns at different levels, since they'd be draggable normally on each workboard:

Superproject (Backlog) > Project (In Progress) > Subproject (Soon)

From a product perspective, this would be more complex to communicate in the UI: today, we can generally collapse most of the hierarchy in most cases, but would be less able to do so with meaningful columns at each level.

As a user, it would be much more work to maintain: depending on how you use columns, you might need to drag each task on several different workboards to update its status properly, and there would be nothing to stop it from getting out of sync. I suspect these tasks would routinely be out of sync on most of the parent workboards.

This would create other issues, too. For example, without additional indicators, it wouldn't be obvious that dragging a project on a workboard to a milestone column would sometimes remove its subprojects. This is tractable, but I think any indicator we add would be less intuitive than subproject columns.

Subproject columns require one additional complexity over how the UI works today (the possibility that a card may appear in multiple columns) but this complexity is fairly well contained, will probably not be hugely common, and should align fairly well with expectations for these tasks which really belong to multiple subprojects -- it's a big complexity from a technical viewpoint, but I think a fairly small complexity from a user viewpoint. Adding this complexity allows us to avoid a number of other more far-reaching/user-facing complexities, like presence in multiple columns.

Broadly, I think the two above comments are expressing a mixture of two ideas:

1. Would this be a better product without subproject columns?
2. Would this be delivered sooner without subproject columns?

For (1), I believe the answer is "no", and that subproject columns are the best way to accept this complexity into the product from a usability viewpoint, as discussed immediately above (T11036#197917).

For (2), the answer is firmly "no". This (and essentially all other tasks) are blocked essentially only by priorities, not by implementation complexity. No matter how simple the proposed implementation is, we won't begin work here until about the same time and the delivery date will change very little.

Arguing for a simpler implementation reduces the wait time only by the difference in implementation times, which is likely a few hours. This task has spent 5 months in queue already and will spend more time there (probably many more months) before we get to it, so the difference in delivery schedule for a 1-hour or 20-hour implementation is almost nothing (a tiny fraction of the total timeline). In essentially all cases, you are best served by arguing for a better version of the feature, even if that version is more complex, since if you convince us to spend 30 hours on it instead of 20 you'll only be pushing the timeline back by a tiny fraction of a percent but you'll get a better product.

If you'd like to better understand our planning process (which is essentially the only thing that impacts when we deliver features -- delivery timelines and implementation complexity are virtually unrelated), see Planning.

Ok, thanks for the explanation!

The only problem currently is that tasks disappear when they are assigned to a subproject with no workboard of its own. The new subproject columns on the parent project workboard seem to fix that.

my current view is basically that the official subprojects implementation only makes this much more clunky and restricts some parts of it, rather than moves it forward. As it is, the current subproject implementation doesn't seem to do much else than make a couple of links appear, and restrict the usage of some features (tagging and project membership handling are changed/restricted, at least).

Agreed. None of my teams use subprojects because of this. Milestones are much more distinct and useful. This thread appears to be a conversation dedicated to making subprojects into columns, but I wonder why add that functionality when it is seemingly redundant with the existing Milestone functionality. If the issue is "disappearing" tasks (when they get tagged with a subproject that has no board) I think it's a much simpler solution to just automatically tag any subproject task with the parent project (and thus all the tasks of a parent project and its children/subprojects exists in a central location). As it is, Herald can do this already, so I question the value of spending time on implementing an auto tag.

Since my teams don't see a use for subprojects (as their functionality is basically already there in standard tagging), and great use for Milestones, my main concern is the inability to move Milestone columns at will on a board.

I do not plan to ever let you reorder milestones.

If you need that feature specifically and other similar approaches are not acceptable in your use case, the only pathway available to you is to fork Phabricator and implement it locally.

@epriestley, sure, I was not (intentionally) trying to be against subproject columns per se. I think they are a good way forward for making subprojects more usable.

My main concern is that even with them, subprojects are still too static to be relied upon. They still offer pretty little on top of tagging (in my most humble opinion), and they impose a pretty hefty amount of reinforced concrete by forcing the parent-child relationships completely statically, and forever. For our use, for example, I can easily come up with dozens (dozens, I say!) situations where we would unexpectedly need to rearrange our project hierarchy since we are using it for product management. We might now have a single version of a product, but immediately when we make a second one, we may want to move both of them under an umbrella. Or not, so it does not make sense to have umbrellas in advance. Et cetera.

All this does not of course mean that others wouldn't find this feature very useful.