Changes between Version 7 and Version 8 of TracDev/Proposals/MultipleProject

Timestamp:

Sep 13, 2010, 5:28:52 PM (14 years ago)

Author:

mjklaim@…

Comment:

Added some points about independant ticket-workflows

TracDev/Proposals/MultipleProject

@@ -170 +170 @@
 Having one workflow per project could quickly make the maintenance of workflows quite complex. To balance this complexity, in hierarchical setups, one could define a workflow at the upper level, and have sub-projects use the workflow defined closest in the hierarchy. For example, one could define a workflow on the root project, and every other project uses this. If one exception has to be defined for a given project, that project can define its own.
 
-Alternatively (ticket:130#comment:159), workflows could be defined as independent entities, and a project will have to be associated to a given workflow (a bit like repositories will be associated to projects).
+Alternatively (ticket:130#comment:159), workflows could be defined as independent entities, and a project will have to be associated to a given workflow (a bit like repositories will be associated to projects). Having workflows as separate entities would allow :
+ - sharing the same workflow between different projects, but still having the possibility to set another workflow for some specific projects;
+ - (might) allow (the user?) to specify explicitely how to manage moving a ticket from one installed workflow to another installed workflow - whatever the project;
+ - ease sharing workflows between users: having workflows encapsulated encourages implementation of several generic workflow solutions (that can be easily tweaked for specific use) that could be worked and provided by default or in a file repository - that would even ease to choose the starting workflow of a new TRAC user;
+