Very happy to see that you guys are working on this, thank you. 👍

In D16859#221192, @maartenbrakkee wrote:

In D16859#199674, @kislinsk wrote:

[...]
I agree that this feature can be implemented as an extension, which I actually did in the beginning and then switched to a contribution for the following reasons:
[...]

Hi @kislinsk, do you still have this functionality as an extension? If so, can you share it?

In T12593#220668, @epriestley wrote:

I'm going to merge this into T12374.

If you have time, answering the questions in T12374#214870 on that task might be helpful. There are many possible implementations of this feature (e.g., per user/per workboard/global) and it's not clear to me which are desired from the use cases. It would also be helpful to understand what the major stumbling blocks are for using "bookmarks" and "saving queries to the menu" as workarounds (just cumbersome? Not the right scope/audience?).

Thank you very much for the detailed answer, @epriestley.

• Executed arc liberate
• Executed arc diff from Linux machine to get linters and unit tests to work

Thanks.

Since this is a highly desired feature for us and many other Phabricator users (tokens, tokens, tokens), I would really like to contribute. I already did some work and it turned out - thanks to the flexible architecture of Phabricator - not that much is needed to get something quite nice and robust:

• A typeahead datasource for project columns
• A new Herald field for task cards
• A new condition type in HeraldAdapter class
• Minor extension of the project column query class

Internally, we track "explicit members" and "implicit members".

Parent projects can not have explicit members. The explicit members are moved.

However, all members of subprojects are implicitly members of ancestors, so they're still present as implicit members of the parent.

I'm hoping to navigate this without adding more concepts to the UI like "explicit members" and "implicit members". One thing I'd like to do is show which subproject(s) a user is a member of in the "Members" panel for parent projects, which might help. We could also add a line of explanatory text, and/or rename the panel to "Members of Subprojects", although both clutter the UI to explain a one-time facet of the model.

We just played around with projects, subprojects, and milestones as we wanted to figure out a nice way of organizing work. We fell over a few inconsistencies/issues/bugs:

In T10349#159385, @epriestley wrote:

@kislinsk In cases like the one you describe (which I consider reasonable), what's your major concern with naming the subproject "ABC (Core)" to resolve the ambiguity of a task tagged with both "ABC > Core" and "XYZ > Core"?

(I generally agree that we probably do need more default or optional disambiguation here, but want to make sure we're making the best tradeoffs we can as we move forward.)

My thoughts on the subproject UI concerns: We were really looking forward to subprojects especially to simplify organization of software components and their appearance in the UI. For example, we have multiple projects managed by the same Phabricator instance and software projects tend to have the same name for many software components like Core, UI, and so on.

Wow, now that was quick @shrinidhirao. 🚀
At least for MITK-ProjectTemplate it works like a charm, thank you!

We have the same problem when importing existing git repositories: