Changes between Version 10 and Version 11 of TracDev/Proposals/MultipleProject
- Timestamp:
- Nov 23, 2014, 10:05:41 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/Proposals/MultipleProject
v10 v11 8 8 Trac has to be adaptable to these different views. The current approach of setting up different Trac environments only allows to get a fixed view on one project. By using InterTrac links, it has been possible to relate resources one to another across Tracs, but the interaction and sharing of information couldn't go beyond linking: no common search or ticket queries, no shared timeline, no possibility to conveniently move resources from one project to the next while retaining the full history, etc. 9 9 10 In addition, for some database back ends, the single project per environment design impose practical limits to the number of projects that can be run concurrently, due to connection sharing concerns (#8058).10 In addition, for some database back-ends, the single project per environment design impose practical limits to the number of projects that can be run concurrently, due to connection sharing concerns (#8058). 11 11 12 12 The next step is therefore to provide the ability to create multiple Trac projects and sub-projects inside a single environment and to offer some convenient ways to form "views" on which projects should be active for a given request. 13 13 14 In our usual tradition of backward compatibility, when an environment only contains the top level project everything should continue to work like it always did. This will allow alternate implementations of multiple project setups to continue working unmodified (see the various TracMultipleProjects sub-pages, esp. TracMultipleProjects/SingleEnvironment which contains a proposal quite similar to this: adding a project field and a Projects table).14 In our usual tradition of backward compatibility, when an environment only contains the top-level project everything should continue to work like it always did. This will allow alternate implementations of multiple project setups to continue working unmodified (see the various TracMultipleProjects sub-pages, esp. TracMultipleProjects/SingleEnvironment which contains a proposal quite similar to this: adding a project field and a Projects table). 15 15 16 16 … … 20 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 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.22 This approach accommodates with the simplest case of the top-level project being the only project, supports quite well the situation of having many independent projects by creating all projects as sub-projects of the top-level 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 23 24 24 Here are some typical setups: 25 25 26 26 Single project:: 27 - "" or "/", the ''top level project''27 - "" or "/", the ''top-level project'' 28 28 29 29 Several independent projects:: 30 - "" or "/", the ''top level project''31 - " project_a"32 - " project_b"33 - " project_c"30 - "" or "/", the ''top-level project'' 31 - "//project_a//" 32 - "//project_b//" 33 - "//project_c//" 34 34 35 35 Hierarchy of projects:: 36 - "" or "/", the ''top level 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"36 - "" or "/", the ''top-level 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 45 - ... 46 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). 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. 58 49 59 50 Example: … … 89 80 </fieldset> 90 81 }}} 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 82 83 === Focal project 84 However the hierarchy can help to intuitively select a **meaningful subset** of the existing projects. 94 85 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.86 To complement the project selector user interface shown above, we could also have a simpler interface (a selection) which would allow the user 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. 96 87 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. 88 {{{#!html 89 <select> 90 <option> </option> 91 <option value="1231">Family A</option> 92 <option value="1243">┗ product a</option> 93 <option value="1245">┗ product b</option> 94 <option value="1236" selected>Family B</option> 95 <option value="1255">┗ product c</option> 96 <option value="1277">┗ product d</option> 97 <option value="231">Tools</option> 98 <option value="233">3rd Party</option> 99 </select> 100 }}} 98 101 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.102 For example, if that center of interest is set to "//Family B//", then the selected projects will be the top-level one, "//Family B//" itself, "//product c//" and "//product d//", but not the siblings of "//Family B//", i.e. what has been hand-picked in the Project Selector example above. 100 103 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. 104 Such a selection is meaningful because it usually makes sense to work at a given level and be interested in all what's happening in sub-projects but also to be aware of issues happening at higher level which may impact the current project and sub-projects as well. 102 105 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.106 In practice and for this example, this means that when looking for tickets, one would see all the tickets associated with sub-projects ("//products c//" and "//project d//"), but also tickets directly associated with the "//Family B//" project (e.g. installer issues), and tickets directly associated with the top-level project (e.g. bugs in the web site shared by all projects). 104 107 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. 108 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 be possible to select ''only'' "//Family B//" without selecting its ancestor projects or sub-projects, to consider only tickets directly associated with this level. 109 110 === Projects and milestones, versions, ... 111 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 created, "//product c//" issues could be directly targeted to this "//B-1//" milestone. 112 113 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 top-level "/////" will be shown. The tickets for "//Family B/product_d//" on the other hand won't be visible in that view. 114 115 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 top-level ones associated to this milestone. One can see that this could involve the possibility of having multiple target milestones for a ticket (e.g. a top-level ticket needed for milestone "//B-1//" and "//A-1//"). 116 117 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. 118 119 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 typically be relevant for someone who is working on that project. 120 121 With the "focal project" model, the users will also have a clear guideline for selecting which project should be associated with their resource (be it a ticket, wiki page, milestone, version, component, etc.): the project level at which the given resource is relevant for that project and //all the sub-projects of that project//. Or put differently, you could start with a leaf project and go up until the item is no longer relevant to all the sibling projects of the last level considered. 106 122 107 123 At this early stage of the proposal, this organization seems to be at the same time simple, intuitive yet very powerful.
