| 392 | | (I'm a little out of my depth here, designing for Trac internals I don't understand. Hopefully, more experienced Trac developers will guide me. -- Chris) |
| 393 | | |
| 394 | | To add better project management to Trac in a modular fashion requires defining the interfaces that project management implementations rely on. We'll name these with a common prefix "IProject". The 'I' is for "Interface", a common convention in Trac development. The "Project" might be "PM" or "!ProjMgr" or something. This is certainly open to discussion. |
| | 392 | To maximize the flexibility in mixing and matching plugins to provide features for project management, I propose to leverage Trac's [http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture Component Architecture] to specify a number of interfaces in a `tracpm` namespace. In this way a Gantt chart, a workload chart, a task scheduler, etc. can all use the `tracpm` interfaces regardless of whether, for example, Subtickets of Childtickets (or even ticket decomposition in a future Trac core) are used to represent parent/child relationships. |
