Sometimes it's nature to have a bigger project for many small projects, like parent and child node of a tree data structure. Those small projects could be just small iterations, or going on in parallel with different teams.
It would be nice to have a way to organize and show projects in this parent-children way.
T4100 is complete and this is technically unblocked, but needs significant planning work. I intend to wait until we're closer to being able to act on it to do that planning, since things are likely to change at least somewhat between now and then.
In general, see Planning / Paid Prioritization / Roadmap / Starmap.
See also the weekly development notes, e.g. Development Notes 2015 Week 43.
This is part of "v3" of Projects, which I currently hope to get through before the end of the year, but who knows.
If we have to miss one of those four projects (ApplicationEditor, Projects, Nuance, Phriction) it will probably be Phriction so there's some buffer here, but either this or Nuance might be behind it on the chopping block.
I have a use case which is maybe suited for subprojects, but I don't exactly know how you are planning on implementing this...
Basically, we use projects for a few different purposes, but most importantly we use projects for teams (which is used as a way for a team to claim ownership of a task and for it to show up on the team's workboard) and as tags. Usually I encourage users to file tickets against a tag rather than a team, because teams have a dependency to be restructured and, as a result, sometimes its difficult to know which team owns what. Currently I have a Herald rule along the lines of if [projects contains any of "Some Label"] [add project "Some Team"]. One problem with this approach is that when we restructure teams, it is difficult to backdate tickets. For example, we just formed a new team and, as such, the labels associated with an existing team are going to split up. This is currently difficult to do because it involves bulk editing our entire workboard. Instead, it would be nice if teams could just somehow claim ownership of labels.
This is currently difficult to do because it involves bulk editing our entire workboard
What's difficult about this? Can't you just use the bulk editor to "Remove project X" and "Add project Y"?
Hmm, unless I'm doing it wrong (I've never used the bulk editor before) I can apply bulk edit 100 tasks at a time.
You should be able to batch edit infinite tasks.
Tentatively, projects get new fields:
Projects get new actions:
"Initialize Milestones" is available for projects which are not milestone projects and do not have milestones yet. It creates a new empty subproject called "Milestone 1" by default with milestoneNumber = 1, which is marked as a milestone project, has the original project as its parentProjectPHID, and sets the "hasMilestones" flag on the parent project.
"Create Next Milestone" is available for projects which already have at last one milestone. It creates a new empty subproject called "Milestone N+1" by default, where "N" is the largest milestone number of any subproject ("Milestone 2", "Milestone 3", etc). This project is marked as a milestone project and points at the parent.
"Initialize Subprojects" is available for projects which are not milestone projects and do not have subprojects yet. It creates a new empty subproject with a user-supplied name, which has no special flags. If this is the first subproject, all of the project's members are moved to the subproject. The "hasSubprojects" flag is set on the parent project. The subproject points at the parent.
"Create Subproject" is available for projects that have subprojects. It creates a new empty subproject with a user-supplied name and no special flags. The subproject points at the parent.
The parentProjectPHID flag causes these effects:
The hasSubprojects flag causes these effects:
The hasMilestones flag causes these effects:
The isMilestoneProject flag causes these effects:
The big design issue I'm trying to finesse around here is that there are two conflicting use cases for membership rules: in "Maniphest > Sprint 16", the members of the child should just be the members of the parent. In "Engineering > Backend", the members of the parent should be the union of all the members of the children. These are both reasonable use cases, but have different conflicting rules.
If we address these cases with strong project types (e.g., a project is either a "superproject" or a "milestone project", but not both), I think we'll eventually have a lot of users make mistakes with project types (or have changing needs, or whatever else) and end up in situations they aren't happy with and can't get out of (T7410 discusses similar issues with Workboards). Letting these relationships coexist avoids having "dead-end" workflows where you're stuck with the outcome of a choice. Although giving a project both milestones and normal subprojects probably has no real-world analog, doing one and then regretting it and wanting the other definitely does.
This doesn't specifically allow for changing decisions in two cases:
Regarding the two use cases Engineering -> Backend && TeamX -> Sprint2:
I think you could treat them equally by having the parent project members be those of all the subprojects in both cases. I think it would be a valid usecase to change members from one sprint to the next (retaining the information about old sprints members).
All that's needed would be some magic upon project creation that uses the members from another project as a template (the last sprint or maybe the parent project as default).
Maybe allow the user to create a project template that defines the default members, the project name (sth like Sprint-%Y%m%d) and similar in the parent project and when you create a subproject from it you show the available templates in the dropdown (just like the new Create Task button).
This would only be problematic if you want to remove a users permission completely and have a lot of (active) subprojects. Archived subprojects should not count towards the parents member list.
I think you could treat them equally by having the parent project members be those of all the subprojects in both cases. I think it would be a valid usecase to change members from one sprint to the next (retaining the information about old sprints members).
One concern is that this could leave some users capable of viewing only some sprints. For example, if the parent project has "Visible To: Project's Members" as a policy and user alice is added on Sprint 61, she wouldn't be part of sprints 1 through 60 and couldn't see them. Although it is possible that there are some use cases for this, I suspect it is very rare and the more common use case is that all members of a project should be able to see all the old data. If you do have a material change to project policies at some point (e.g., sprints 1 through 60 were a secret skunkworks, and sprints 61 through infinity are normal public development), I think it seems reasonable to create a new project as a one-time cost to effect a project policy change (e.g., rename the existing project to "Projectname: Secret Early Development" and create a new "Projectname" with more liberal policies).
That is, if I'm added to the "Photos" team, I expect to be able to see what they're currently working on and what they worked on recently, and click through when a teammate says "see Sprint 40 for a similar case". With some reasonable policies, I wouldn't be able to if membership is locked to parent project membership at the time the milestone is created.
This would only be problematic if you want to remove a users permission completely and have a lot of (active) subprojects. Archived subprojects should not count towards the parents member list.
This would potentially leave users as members of projects with conflicting visibility rules: they might not be able to see the "Team X" project (e.g., they are not a member and visibility is "members"), but could see the "Team X > Sprint 4" project (they are a member and membership implies visibility). But by "you must be able to see all parent projects to see a project", they also could not see "Sprint 4". While we could make one of these rules stronger, I think it would lead to confusing cases. The parent/child stuff dodges this by never permitting a situation where these rules are in conflict, which I think is cleaner.
There might be some value to retaining the historic membership data (e.g., maybe we want to draw charts in the future), but we could write this somewhere else and not need it to be the membership list actual (e.g., some "historic list of members of this sprint at the time the next sprint was created, for charting purposes" table somewhere).
project template that defines the default members, the project name (sth like Sprint-%Y%m%d)
I do plan to provide some degree of name customization/templating so that the UI can call these, e.g., "Sprint X/Y/Z" instead of "Milestone N", although this may not show up for a while.
Since this task has upwards of 5 people on it and at least some of the subscribers probably mostly care about the feature being done, I filed T10010 to track granular development progress. You can follow that if you care about individual revisions and implementation details. (I'm not exactly sure when I'm going to get started on it and still need to plan the sequencing on some other related/blocking work, but I think relatively soon.)
I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?
See T10350 for a script to move one project under another. Note that this only works on "flat" projects, i.e. you can't move a project with its own subprojects.