Add subprojects
Closed, ResolvedPublic

Tokens
"Like" token, awarded by rafaelrabeloit."Like" token, awarded by CodeMouse92."Like" token, awarded by featherless."Love" token, awarded by slashsBin."Like" token, awarded by StuC."Like" token, awarded by frogman544."Like" token, awarded by Krinkle."Like" token, awarded by mliberty."Love" token, awarded by Luke081515.2."Manufacturing Defect?" token, awarded by dagomar."Pterodactyl" token, awarded by elsuperoctavio77."Like" token, awarded by t3dev."Manufacturing Defect?" token, awarded by ximion."Love" token, awarded by revi."Evil Spooky Haunted Tree" token, awarded by ivanleonardi."Like" token, awarded by uchti."Like" token, awarded by Cst."Love" token, awarded by johnny-bit."Like" token, awarded by kristen.lans."Love" token, awarded by mholden."Like" token, awarded by nateguchi2."Like" token, awarded by addeo."Like" token, awarded by rahulbalani."Love" token, awarded by nemobis."Love" token, awarded by dacuetu."Like" token, awarded by qgil."Like" token, awarded by r0bbie.
Assigned To
Authored By
wolvever, Aug 2 2013

Description

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.

Related Objects

StatusAssignedTask
Resolvedchad
ResolvedNone
Resolvedepriestley
DuplicateNone
ResolvedNone
OpenNone
OpenNone
Openepriestley
OpenNone
ResolvedNone
ResolvedNone
DuplicateNone
OpenNone
OpenNone
Resolvedepriestley
Resolvedchad
Resolvedepriestley
Wontfixepriestley
OpenNone
OpenNone
Wontfixepriestley
DuplicateNone
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Wontfixepriestley
DuplicateNone
OpenNone
Resolvedbtrahan
Resolvedbtrahan
Resolvedepriestley
ResolvedNone
Resolvedepriestley
Resolvedepriestley
Resolvedbtrahan
Wontfixepriestley
There are a very large number of changes, so older changes are hidden. Show Older Changes
unitof added a subscriber: unitof.Jul 31 2015, 3:57 PM
angie moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Sep 9 2015, 10:28 PM
angie moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

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.

epriestley moved this task from Backlog to Projects v3 on the Projects board.Sep 9 2015, 11:19 PM
Luke081515.2 added a subscriber: Luke081515.2.
carl removed a subscriber: carl.Oct 17 2015, 4:45 AM
cadamo removed a subscriber: cadamo.Oct 19 2015, 4:57 PM
StuC awarded a token.Oct 20 2015, 2:31 PM
StuC added a subscriber: StuC.Oct 20 2015, 2:34 PM
gd added a subscriber: gd.Oct 28 2015, 11:08 AM

We would like to have this too. Is there any timeline for this?

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.

Grimeh added a subscriber: Grimeh.Nov 7 2015, 8:09 PM

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"?

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.

  • From a Workboard, do "Batch Edit Visible Tasks".
  • From Maniphest, set page size to 99999999, then Select AllBatch Edit Selected.

Ah OK, good to know.

featherless added a subscriber: featherless.

Tentatively, projects get new fields:

  • parentProjectPHID
  • hasSubprojects
  • hasMilestones
  • isMilestoneProject
  • milestoneNumber

Projects get new actions:

  • Initialize Milestones
  • Create Next Milestone
  • Initialize Subprojects
  • Create Subproject

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

  • You must be able to see all parent projects to see a project.
  • You must be able to edit any parent project to edit a project.
  • Various UI changes.

The hasSubprojects flag causes these effects:

  • "Initialize Subprojects" becomes "Create Subproject".
  • The project's members can not be edited.
  • The project's membership list is computed dynamically as the union of all non-milestone subproject membership lists.
  • Various UI changes.

The hasMilestones flag causes these effects:

  • "Initialize Milestones" becomes "Create Next Milestone".
  • Various UI changes.

The isMilestoneProject flag causes these effects:

  • The project's members and policies can not be edited.
  • The members and policies are computed dynamically, as being exactly the same as the parent project.
  • The project can not have subprojects or milestones.
  • Various UI changes.

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:

  • You can't easily undo creation of subprojects, although we could add some flags to support that later.
  • You can't easily turn a milestone into anything else, although that doesn't seem important (archive the milestone and split the parent apart instead).
fabe added a comment.Dec 18 2015, 8:15 AM

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.)

samG added a subscriber: samG.Dec 26 2015, 8:02 AM
ablekh added a subscriber: ablekh.Jan 22 2016, 4:38 AM
chad moved this task from Projects v3 to v3 on the Projects board.Feb 5 2016, 7:39 PM
chad edited projects, added Projects (v3); removed Projects.
chad moved this task from Backlog to Evan on the Projects (v3) board.
epriestley closed this task as Resolved.Feb 12 2016, 9:50 PM
epriestley claimed this task.

This is now substantially complete.

  • See T10349 for followups / errata.
  • Guidance on the new features will be forthcoming in the Changelog this evening or tomorrow.
bhush9 added a subscriber: bhush9.Jun 6 2016, 12:38 PM

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?

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.

urzds added a subscriber: urzds.Jul 12 2017, 11:14 AM