| | 15 | |
| | 16 | |
| | 17 | == The Project Tree == #ProjectTree |
| | 18 | |
| | 19 | A very natural way to group projects and sub-projects is to use a ''hierarchy'' of projects. |
| | 20 | The top-level project contains all the other projects, the leaf projects can focus on some appropriate subset of the development activity (e.g. a given library) and the intermediate project nodes in this the project tree are used to group related sub-projects together. |
| | 21 | |
| | 22 | This approach accommodates with the simplest case of a the toplevel project being the only project, supports quite well the situation of having many independent projects by creating all projects as sub-projects of the toplevel project, but also scales to more complex development environments, e.g. where there are different families of products and possibly customer specific sub-projects for each of the products. |
| | 23 | |
| | 24 | Here are some typical setups: |
| | 25 | |
| | 26 | Single project:: |
| | 27 | - "" or "/", the ''toplevel project'' |
| | 28 | |
| | 29 | Several independent projects:: |
| | 30 | - "" or "/", the ''toplevel project'' |
| | 31 | - "project_a" |
| | 32 | - "project_b" |
| | 33 | - "project_c" |
| | 34 | |
| | 35 | Hierarchy of projects:: |
| | 36 | - "" or "/", the ''toplevel project'' |
| | 37 | - "Family A" |
| | 38 | - "Family A/product a" |
| | 39 | - "Family A/product b" |
| | 40 | - "Family B" |
| | 41 | - "Family B/product c" |
| | 42 | - "Family B/product d" |
| | 43 | - "Tools" |
| | 44 | - "3rdParty" |
| | 45 | - ... |
| | 46 | |
| | 47 | The hierarchy doesn't ''limit'' the possible ways of grouping projects. |
| | 48 | In the example above, it should still be possible to search for tickets in "Family A" and "Family B" but not in "Tools" and "3rdParty" when needed, using a reasonably simple user interface. |
| | 49 | |
| | 50 | However the hierarchy can help to intuitively select a meaningful subset of the existing projects. |
| | 51 | For example, a project selector user interface could allow for any subset of projects to be selected, yet provide a straightforward way to pick a project which becomes the ''center of interest''. This means selecting not only that project, but also its ancestor projects and sub-projects. |
| | 52 | |
| | 53 | For example, if that center of interest is set to "Family B" in the above example tree, then the selected projects will be the toplevel one, "Family B" itself, "product c" and "product b". |
| | 54 | |
| | 55 | This means that when looking for tickets, one would see all the tickets from sub-projects (products c and d), but also tickets that address issues concerning the "Family B" as a whole (e.g. installer issues), and tickets that concerns all the projects (e.g. bugs in a base library used by every project). |
| | 56 | |
| | 57 | In the end this is mainly a matter of user interface, and picking up any other subset of projects should be easily possible as well by just toggling a few checkboxes (among other things, it should also be possible to select ''only'' "Family B" without selecting its ancestor projects or sub-projects). |
| | 58 | |
| | 59 | Example: |
| | 60 | {{{ |
| | 61 | #!html |
| | 62 | <fieldset style="display: inline"> |
| | 63 | <legend>Project Selector</legend> |
| | 64 | <form> |
| | 65 | <ul style="list-style-type: none"> |
| | 66 | <li> |
| | 67 | <input type="checkbox" checked="checked">Top-level</input> |
| | 68 | <ul style="list-style-type: none"> |
| | 69 | <li> |
| | 70 | <input type="checkbox">Family A</input> |
| | 71 | <ul style="list-style-type: none"> |
| | 72 | <li><input type="checkbox">product a</input></li> |
| | 73 | <li><input type="checkbox">product b</input></li> |
| | 74 | </ul> |
| | 75 | </li> |
| | 76 | <li> |
| | 77 | <input type="checkbox" checked="checked"><b>Family B</b></input> |
| | 78 | <ul style="list-style-type: none"> |
| | 79 | <li><input type="checkbox" checked="checked">product c</input></li> |
| | 80 | <li><input type="checkbox" checked="checked">product d</input></li> |
| | 81 | </ul> |
| | 82 | </li> |
| | 83 | <li><input type="checkbox">Tools</input></li> |
| | 84 | <li><input type="checkbox">3rdParty</input></li> |
| | 85 | </ul> |
| | 86 | </li> |
| | 87 | </ul> |
| | 88 | </form> |
| | 89 | </fieldset> |
| | 90 | }}} |
| | 91 | The user interface could be as simple as changing the center of interest when clicking on the name of the project. |
| | 92 | Clicking on the checkboxes could be used to select/deselect projects on an individual basis. |
| | 93 | |
| | 94 | |
| | 95 | On a different level, the hierarchy can also be used to organize resource sharing between projects. For example, in the Ticket system we could imagine that milestones belonging to ancestor projects are also visible in their sub-projects. In our hierarchy example above, imagine setting up a milestone for a "B-1" release in the "Family B" project. In sub-projects "product c" and "product d", no redundant milestone setup needs to be done, "product c" issues could be directly targeted to this "B-1" milestone. |
| | 96 | |
| | 97 | In the typical center-of-interest setup, looking at the roadmap when "Family B/product_c" is the center of interest, the "B-1" milestone will show up and the tickets for "Family B/product_c", "Family B" and toplevel "/" will be shown. The tickets for "Family B/product_d" on the other hand won't be visible in that view. |
| | 98 | |
| | 99 | Conversely, when "Family B" is the center of interest, the "B-1" milestone will show the tickets for "Family B/product_c" and "Family B/product_d" (all the sub-projects), "Family B" itself and the toplevel ones associated to this milestone. |
| | 100 | |
| | 101 | In case the project selection is restricted to "Family B" alone (no ancestors, no sub-projects), then the "B-1" milestone will naturally only show the tickets belonging to the "Family B" project. |
| | 102 | |
| | 103 | So we see that the current project selection is always used to filter the set of resources that are taken into account for any kind of data retrieval. The default project selection obtained by selecting a "center of interest" project (focal project?), consisting of the project itself, its ancestors and its sub-projects provides a view on all the resources which should be generally relevant for someone who is working in that project. |
| | 104 | |
| | 105 | With this "center-of-interest" model, the users will also have a clear guideline for selecting the project in which they should create their resource (be it a ticket, wiki page, milestone, version, component, etc.): they should pick the project for which it makes sense to see the resource from all the project's sub-projects. |
| | 106 | |
| | 107 | At this early stage of the proposal, this organization seems to be at the same time simple, intuitive yet very powerful. |
