Interesting question.

I'm 2% sure that somewhere there is a table describing the whole situation and describing this as a "feature". I'm reading this now but I need some time to have a clear idea:

https://we.phorge.it/book/phorge/article/projects/

To be honest this could create a performance issue in my installation, since I use Sub-Projects as a simple way to collect many Projects that must be grouped but that have different features.

To give an idea, I will replace my concepts with stuff related to Phorge and social networks:

Phorge
   Column 1
   Milestone 1
   Milestone 2
   Admins              → Workboard where new admin are evaluated / fired, adding/removing SSH keys on servers etc.
   Office              → Workboard where the office talks about things like problems with invoices about Phorge etc.
   Ad-Hoc customers    → Workboard where new customers are evaluated
      Facebook         → Workboard with their Phorge ad-hoc customizations that are totally unrelated from others
      Amazon           → Workboard with their Phorge ad-hoc customizations that are totally unrelated from others
      150+ customers   → ...

And then again with other things (this is not another alternative example, this is really an attempt to describe another example in place at the same time):

Puzzle Bubble
   Column 1
   Column 2
   Milestone 1
   Milestone 2
   Admins              → Workboard where new admin are evaluated / fired, adding/removing SSH keys on servers etc.
   Office              → Workboard where the office talks about things like problems with invoices about Phorge etc.
   Ad-Hoc customers    → Workboard where new customers are evaluated
      Apple            → Workboard with their Phorge ad-hoc customizations that are totally unrelated from others
      EvilCorp         → Workboard with their Phorge ad-hoc customizations that are totally unrelated from others
      Facebook         → Workboard with their Phorge ad-hoc customizations that are totally unrelated from others (and also unrelated to Facebook mentioned before)
      150+ customers   → ...

So at the moment we use to visit the Puzzle Bubble Workboard to work on the features organized in different Columns and Milestones and that's all. These Tasks also appears on the related Customer's Workboard of course. Note that the Puzzle Bubble Workboard shows "All the Tasks", not just the Open ones, since the past is important to make future decisions.

This is really an ideal organization in the company I work for, since from the perspective of the company it would really make no sense to have Facebook as a root project, since its purpose depends from what product that customer is actually using, and so the PuzzleBubble>Facebook and Phorge>Facebook are totally unrelated, these customers are really different entities even when they have the same name. Also, having them as root Projects would flood my installation with root crap. Instead, with this tree organization, thanks to the fact the parent project has some custom visibility, users not involved in Puzzle Bubble does not see the customers of Phorge and so their point of view is not flooded by crappy unrelated topics (and it would be a terrible struggle to manage this visibility if they were all root-projects - so again, having a sub-projects is OK for us).

The problem with this situation is: if I will visit the Workboard of the Project named Ad-Hoc customers, it will load 150+ other workboards.

I mean: probably that could be useful also to my situation to have an overview of what they are asking (that again, 99% of the time it has no impact between customers and/or between other products), so, perhaps it would deserve a different loading system since the server would have a nice spike with each visit. That spike could also be dramatic, since all these Workboards we usually want to filter them as "Show all Tasks".

So, even in my case, I'm probably not against this, but just a little cautious. Also, I'm curious about other use cases.

I like the fact that, what is proposed here, is somehow what GitLab does as default I think:

https://gitlab.com/ItalianLinuxSociety

https://gitlab.com/groups/ItalianLinuxSociety/-/boards

That is a parent project, with many child projects, but the default board shows all the issues also from parent projects.

So maybe what is proposed here it could clarify some things to beginners.

Apart from my wall of text, having said that a Task cannot stay in multiple Milestones from the same project, so on the Workboard you never see duplicates, this is the current blocking:

So, probably this simply cannot be done as-is now, without deciding what to do, to avoid duplicate Tasks on the same Workboards, when we will somehow introduce this feature

In T15231#5924, @valerio.bozzolan wrote:

Apart from my wall of text, having said that a Task cannot stay in multiple Milestones from the same project, so on the Workboard you never see duplicates, this is the current blocking:

a Task can be attached to multiple Sub-Projects

So, probably this simply cannot be done as-is now, without deciding what to do, to avoid duplicate Tasks on the same Workboards, when we will somehow introduce this feature

I think that we can't really fix this blocking part right now. Since a Task can be in multiple Sub-Project, or both in the parent and in the Sub-Project, so it's unclear what should be done in these cases. e.g. Displaying a Task twice?

Edited: wow, nice. It seems upstream already decided to support viewing the same Task multiple times on a Workboard. Green light in that case.

I think I just imagined replacing the (default) query from "tasks tagged with project X" to "tasks tagged with project X or any subproject of X".

Having the same ticket in multiple columns can be confusing, especially if the board isn't read-only.

(Also found https://secure.phabricator.com/T11036 for this exact issue)

Maybe we can start implementing this just like the way the Show hidden Columns top-right Workboard menu was implemented: so, we add a Show Sub-Projects as a way to use that filter, but not as default.
This can give a margin of creativity to change things without much complaints, and still gives the ability to have a permalink to that situation, and so, allowing to adopt that view as default.

Just to clarify as a side note, this will probably not solve the problem of people wanting to reorder their Milestones.

People who use Milestones use them as "version 123," "version 124," etc. and will not start using Sub-projects for this, mainly because a Task should not be able to be in two versions, and this desired limitation is typical of a Milestone, and not of Sub-projects.