Changeset View
Changeset View
Standalone View
Standalone View
src/docs/user/userguide/projects.diviner
| Show First 20 Lines • Show All 129 Lines • ▼ Show 20 Lines | |||||
| tasks, change the default item to the workboard instead of the profile to get | tasks, change the default item to the workboard instead of the profile to get | ||||
| to the workboard view more easily. | to the workboard view more easily. | ||||
| **Hide Unused Items**: If you have a project which you don't expect to have | **Hide Unused Items**: If you have a project which you don't expect to have | ||||
| members or won't have a workboard, you can hide these items to streamline the | members or won't have a workboard, you can hide these items to streamline the | ||||
| menu. | menu. | ||||
| Subprojects and Milestones | |||||
| ========================== | |||||
| IMPORTANT: This feature is only partially implemented. | |||||
| After creating a project, you can use the | |||||
| {nav icon="sitemap", name="Subprojects"} menu item to add subprojects or | |||||
| milestones. | |||||
| **Subprojects** are projects that are contained inside the main project. You | |||||
| can use them to break large or complex groups, tags, lists, or undertakings | |||||
| apart into smaller pieces. | |||||
| **Milestones** are a special kind of subproject for organizing tasks into | |||||
| blocks of work. You can use them to implement sprints, iterations, milestones, | |||||
| versions, etc. | |||||
| Subprojects and milestones have some additional special behaviors and rules, | |||||
| particularly around policies and membership. See below for details. | |||||
| This is a brief summary of the major differences between normal projects, | |||||
| subprojects, parent projects, and milestones. | |||||
| | | Normal | Parent | Subproject | Milestone | | |||||
| |---|---|---|---|---| | |||||
| | //Members// | Yes | Union of Subprojects | Yes | Same as Parent | | |||||
| | //Policies// | Yes | Yes | Affected by Parent | Same as Parent | | |||||
| | //Workboard// | Yes | No Custom Columns | Yes | Yes | | |||||
| | //Hashtags// | Yes | Yes | Yes | Special | | |||||
| Subprojects | |||||
| =========== | |||||
| Subprojects are full-power projects that are contained inside some parent | |||||
| project. You can use them to divide a large or complex project into smaller | |||||
| parts. | |||||
| Subprojects have normal members and normal policies, but note that the policies | |||||
| of the parent project affect the policies of the subproject (see "Parent | |||||
| Projects", below). | |||||
| Subprojects can have their own subprojects, milestones, or both. If a | |||||
| subproject has its own subprojects, it is both a subproject and a parent | |||||
| project. Thus, the parent project rules apply to it, and are stronger than the | |||||
| subproject rules. | |||||
| Subprojects can have normal workboards. | |||||
| Milestones | |||||
| ========== | |||||
| Milestones are simple subprojects for tracking sprints, iterations, versions, | |||||
| or other similar blocks of work. Milestones make it easier to create and manage | |||||
| a large number of similar subprojects (for example: {nav Sprint 1}, | |||||
| {nav Sprint 2}, {nav Sprint 3}, etc). | |||||
| Milestones can not have direct members or policies. Instead, the membership | |||||
| and policies of a milestones are always the same as the milestone's parent | |||||
| project. This makes large numbers of milestones more manageable when changes | |||||
| occur. | |||||
| Milestones can not have subprojects, and can not have their own milestones. | |||||
| By default, Milestones do not have their own hashtags. | |||||
| Milestones can have normal workboards. | |||||
| Parent Projects | |||||
| =============== | |||||
| When you add the first subproject to an existing project, it is converted into | |||||
| a **parent project**. Parent projects have some special rules. | |||||
| **No Direct Members**: Parent projects can not have members of their own. | |||||
| Instead, all of the users who are members of any subproject count as members | |||||
| of the parent project. By joining (or leaving) a subproject, a user is | |||||
| implicitly added to (or removed from) all ancestors of that project. | |||||
| Consequently, when you add the first subproject to an existing project, all of | |||||
| the project's current members are moved to become members of the subproject | |||||
| instead. Implicitly, they will remain members of the parent project because the | |||||
| parent project is an ancestor of the new subproject. | |||||
| You can edit the project afterward to change or remove members if you want to | |||||
| split membership apart in a more granular way across multiple new subprojects. | |||||
| **No Workboard Columns**: Parent projects can not have their own workboard | |||||
| columns: instead, the workboard of a parent project shows columns representing | |||||
| the child projects. | |||||
| Thus, a project's workboard columns are destroyed when you add the first | |||||
| subproject. All objects on the workboard will be returned to the project's | |||||
| backlog. The new board will show columns for subprojects instead. | |||||
| **Searching**: When you search for a parent project, results for any subproject | |||||
| are returned. For example, if you search for {nav Engineering}, your query will | |||||
| match results in {nav Engineering} itself, but also subprojects like | |||||
| {nav Engineering > Warp Drive} and {nav Engineering > Shield Batteries}. | |||||
| **Policy Effects**: To view a subproject or milestone, you must be able to | |||||
| view the parent project. As a result, the parent project's view policy now | |||||
| affects child projects. If you restrict the visibility of the parent, you also | |||||
| restrict the visibility of the children. | |||||
| In contrast, permission to edit a parent project grants permission to edit | |||||
| any subproject. If a user can {nav Root Project}, they can also edit | |||||
| {nav Root Project > Child} and {nav Root Project > Child > Sprint 3}. | |||||
| Policies In Depth | Policies In Depth | ||||
| ================= | ================= | ||||
| As discussed above, adding and removing projects never affects who can see an | As discussed above, adding and removing projects never affects who can see an | ||||
| object. This is an explicit product design choice aimed at reducing the | object. This is an explicit product design choice aimed at reducing the | ||||
| complexity of policy management. | complexity of policy management. | ||||
| Phabricator projects are a flexible, general-purpose, freeform tool. This is a | Phabricator projects are a flexible, general-purpose, freeform tool. This is a | ||||
| ▲ Show 20 Lines • Show All 58 Lines • Show Last 20 Lines | |||||