Kiran, Rafael, I'm not touting the FQP as the cure for all ills; I would just like us to work together rather than pulling in different directions. Project planning and process tracking is the premier applications of TWiki in a corporate environment. And as Peter points out, everybody does it slightly differently. Some people have to adhere to standard methodologies, or use corporate lingo (Kiran, more than their eyes would glaze over; I know the chip design environment very well indeed ). I'm not saying there isn't a place for the ProjectPlannerPlugin - there absolutely is. I expect other planning methodologies will emerge in other plugins as well. What I am concerned about is that each new implementation isn't just reinventing the wheel each time.

What I'd like to get to is a common substrate of functionality that we can all leverage to create/customise different planning paradigms. To me, that means pulling out common sections of all three plugins and building them up into a library of common code. I've done it with the FormQueryPlugin (which has has the DBCachePlugin and MacrosPlugin pulled out of it, and functionality such as gauges dropped in favour of other plugins).

It's all too easy just to take the selfish line and throw functionality over the fence and let the community try to pick up the scraps. Look at the number of dead one-man projects on sourceforge to see this illustrated. It's much harder to actually contribute something back that isn't directly of benefit to you - but that's what Open Source is all about.

-- CrawfordCurrie - 06 Aug 2004

Of course, I am more than willing to try to define a good common platform and architect a good plugin. I wanted to have a web enabled solution and after searching for good-fit solutions, had to resist the temptation to write my own cgi-scripts I think I distilled the requirements and feedback from my group into just the code than actually writing a requirements doc. Actually, before I did the project planner plugin, I did hack the SpreadSheetPlugin and EditTablePlugin a lot to generate similar summaries from one table of tasks. I was doing column vector products, vector divides, column subset selections etc. in SpreadSheetPlugin. I realized that while I was doing it I already broke the object model in it.

If we can define a common model for project planner then I am willing to help in defining and contributing code as much as I can.

-- KiranBondalapati - 06 Aug 2004

Here are some common code opportunities I already know about:

• In the FormQueryPlugin I wrote some code that parsed tables out of topics and embedded them in the twiki data model used by the DBCachePlugin.
  • I had to do column sums, but that is the most complex processing the FQP does (the planning model we used in Motorola was very simple). It would be interesting to code in the kinds of functions you describe on the DBCachePlugin, to support planner/tracker functions.
  • The data model abstracts topic reading, allowing the plugin using the DBCache to focus on presentation and content
• I have wanted to collapse the functionality of the ActionTrackerPlugin and the FormQueryPlugin for a long time. The FQP already supports notification based on generated topic content (you write a topic search, for example, in a specified format. The rendered page is then parsed and notifications generated appropriately). This could be moved into a shared code module.

And WIBNIFs (wouldn't it be nice if):

• we had a Gantt-chart generator that could be driven from the twiki data model.
• there was some way to plug in other presentation modules other than Gantt
• there was consistency/reuse with ThomasWeigert's state model for topics (see WorkFlowAddOn)

I'm sure you (Kiran, Rafael) have code that should/could be reused as well, or can already address my WIBNIFs

-- CrawfordCurrie - 08 Aug 2004

on the WIBNIF's

• yes please though I have this suspicion that I'm going to have to start getting into the "advocating pure wiki" side fo things to balance out the strong application/workflow server stream (which will be hard )

-- SvenDowideit - 08 Aug 2004

(just throwing ideas at the wall, in no particular order)

Common tasks in XpTrackerPlugin

Speaking from the XpTrackerPlugin point of view, the repetitive tasks are:

• Read all the stories for an Iteration, and sumarize the info
• Read a Story (with it's tasks) and sumarize the info
• Render the html form to create a new Project/Team/Iteration/Story
• Render a list of values as html list
• Render a html lightweight gauge with 2 colors
• Given a Story, get its tasks
• Calculate which percentage of b is a
• Determine the status of a Story/Task, percentage completed and overrun incurred, given the estimate, time spent and remaining time

This list was compiled looking at the Common and HtmlUtil modules, where most of the duplicated code recides.

The plugin also provides an object model for Iterations, Stories and Tasks, and a nice way to translate terms (in V3.3) so you can rename Iteration to Phases and such.

Another thing that can be extracted is the nice javascript that sorts a html table without reloading the page. It was already mentioned in TablePluginDev.

Use FQP and DBCachePlugin as Backend

When I readed CrawfordCurrie post about FQP and DBCachePlugin I toyed with the idea to use FQP as the backend for XpTrackingPlugin, because most of the thing it needs (read and sumarize data in tables) are already there and the FQP give the power to do "ad-hoc" reports.

Project/Process tracking plugin concerns

A project/process tracking plugin has 2 main concerns:

• Represent the data
• Show reports using that data

In all three options (XpTrackerPlugin, ProjectPlannerPlugin and FQP) the information is stored in tables (or TWiki forms), and the reports are more or less the same.

Basically what I'm saying is that FQP (and DBCachePlugin) provides much of the backend needed for a tracking plugin in terms of generic data storing and retrieval.

Common structure?

I don't know if the object model used in XpTrackerPlugin could be reused (and expanded?). I see that the following hierarchy is more or less universal (with different names, of course):

Project
|-- Plan or Phase or Iteration
    |-- Activities or Stories or Tasks
        |-- SubActivities or Tasks or Subtasks

Also, every project has (at least) one team.

Proposal

Using the DBCachePlugin along with the proposed object model allows new plugin writers to reuse most of the code, so they only need to concentrate in creating the templates for their pages and write the code for retrieving the data from those topics (using the functions provided by DBCachePlugin).

For simple project/process tracking, using the whole FQP as backend seems like a good idea.

-- RafaelAlvarez - 09 Aug 2004

sorry guys, I have been pretty busy supporting heavy use the plugin at our site and have not been able to contribute much to the thinking and discussion. Fixes and features that resulted from our usage have been uploaded as version 2.0 of the ProjectPlannerPlugin. I will be back soon, I promise

-- KiranBondalapati - 20 Aug 2004