create new tag
, view all tags

Codev Workflow Restructuring

This topic was begun after BeijingRelease to discuss changes to workflow on the Codev web. The MasterRefactor had been attempted but had stalled, and we needed to pick some new directions. Since then a lot of discussion has occurred, and a number of things have been implemented. Others were discussed but never actually completed. The highlights:


  • It is generally agreed that most topics on Codev represent tasks, so "topic" and "task" are used interchangeably unless the difference is important.
  • AssignedTo and AssignedToCore fields were added to allow tracking of who takes responsibility for work on a task.
  • ScheduledFor was set up to allow a task to be designated for completion by a certain release, or by the next beta or alpha.
    • It was noted that ScheduledFor is not very useful for bug fixes, while ImplementationDate is not needed for feature changes.
    • ScheduledFor and the progress fields are useful to roll everything up that made it into particular a release
    • The ImplementationDate could be retired since the "ScheduledFor" already implies it to a "near date"
  • The old manual NiceToHave lists in the release topics are now automatically generated by a search.


  • There was a discussion about splitting Codev up into multiple webs based on a number of schemes.
    • This would be a major undertaking, and probably painful. Is it worth it?
    • Possible new web foci:
      • FeatureBrainstorming/NextGeneration discussion
      • Coded or work-in-progress features/bug fixes
      • Changes already accepted into the core, and preferably also fully documented
      • An archive of outdated or otherwise retired Codev topics that are no longer relevant
  • Another idea was to use multiple WebForms for different topic types.
    • All of these would share the TopicClassification field to allow global searches to use that field to find any topic.
    • Some examples include
      • Non-development Discussion (e.g. this topic)
      • Brainstorming
      • Feature Enhancement Task
      • Bug Report/Bugfix Task
    • The result of this was the a set of two forms, WebForm and BasicForm
      • WebForm has all the progress indicators and is task-oriented.
      • BasicForm is for topics where all of the task-oriented fields are irrelevant.
  • SvenDowideit proposed using an entirely WebForms-based approach to task tracking, with no or minimal freeform editing. He has implemented such a system and is willing to set up a test web on twiki.org for us to try it out.
  • A suggestion was made that field-level access-control would be good for the above CoreTeam restriction, and that it might be a good idea to implement it in TWiki.
    • Which can already be done with the - yet to be documented - label field and an admin page to change those fields -- PTh


-- SamHasler - 07 Sep 2004
-- MattWilkie - 04 Jun 2003
-- RichardDonkin - 26 Aug 2003
-- MartinCleaver - 17 Aug 2003
-- PeterMasiar - 22 Aug 2003
-- PeterKlausner - 25 Aug 2003
-- MS - 26 Aug 2003
-- PeterThoeny - 09 Sep 2003
-- JohnTalintyre - 10 Sep 2003
-- SvenDowideit - 10 Sep 2003

Note: I've rather mercilessly refactored the comments from all of the above authors. Please add any important points to the list above that I managed to miss in my reading through the topic.

-- WalterMundt - 11 Feb 2004

Further Discussion:

Sven - would you see TWiki competing with the likes of Bugzilla and workflow in things like SourceForge and Collabra offerings? If so, how do you see the TWiki base/approach as better?

-- JohnTalintyre - 10 Sep 2003

to answer this properly would require an essay that would take me months to research and write ..

but off the cuff (with a strong slant towards Software development processes):

I don't see TWiki as a plugin replacement for currently used processes and programs. Rather a tool to augment and extend them, and when appropriate, replace those that are showing their limitations.

TWikiForGForge for example, I would see us working towards providing a documentation, discussion and public forum that integrates with the GForge infrastructure. This integration would include hooks and plugins so it would be possible to use the TWiki as a replacement frontend (someone even asked on the GForgeForums if they could do it). When AndreaSterbini and I played with the idea in PoorManWorkFlow we were only talking about data stored in the TWikiTopics, but i was discussing with my co-workersw the idea of think treating any regular datasource (RSS, SOAP, CVS, Bugzilla, screenscraping) as a Topicable resource that we can render, query and process.

At Unisys I implemented a table & workflow based system that was definabled using user editable (no hidden fields) data and page definitions (at the time i also added a scheme for users to editing page templates through the twiki web interface (i made all templates a TWikiTopic)), but i left there just after the first feature iteration (this was all before your META work was released).

The TWiki code base has become more complex since i did this (at the time i mostly genericised the existing code), but it is still my vision for a collaboration integration tool. I want to be able to give myself and my users the ability to change everything, and get data from everywhere (well, at least data from within the company data-sources)

At Unisys we wanted a flexible DocumentManagementSystem to add to our use of the TWiki as an internal KnowledgeBase, and we were designing it with the full SDLC in mind (so each part of the Document's lifecycle could be tracked and managed). At HsaSystems, I'm trying to (slowly) work towards an integrated Project Management system with Requirements tracking, Task Management and Documentation (for release to Clients). This does not mean that the data is all stored in the TWiki. Just that it is the integrating interface, with the ability for us to modify the processes using a high level of abstraction (rather than needing to ask the DBA to make a new SQLForm..)

(ok, thats 1hr of off the cuff smile please help me make my braindump more clear buy refactoring where-ever its not (we can work towards a common understanding as we go))

TODO: i needed to add info about:

  • Greedy Linking
  • better support for DocumentMode - how about rendering the last significant edit more obviously when you do a normal view (that way this new text would be obvious without needing to resort to diffs) - maybe use a URL parameter from WebChanges to set this (see SvenDowideit for the begining of this idea)
    • I've taken to disliking ThreadMode as it leads to a huge amount of text, a huge number of topics and lots of duplication
  • seperate out different data types to allow movement of backend sources
  • changing the focus away from plugins
  • make it possible to use TWikiWorkFlow for TWikiConfiguration
    1. have a runonce wizard that happens the first time the installer accesses any page on thier newly installed TWiki
    2. this takes them through a series of Topics that will allow everything to be configured (with lots of info)
    3. if at any time in the process they exit, they can caome back later from where they left off
    4. i think this should be part of a ConfigWeb so it does not polute the normal TWikiWebSpace
    5. the TWikiAdmins can go back at any time to change settings, create Webs etc..
    6. if this uses TWikiInfrastructure, like TWikiMetadata and TWikiWorkflow then those features will become more complete (in the same way as if we use them for TaskTracking)
  • the need for distributed TWiki (I work in a small company with 3-4 office locations, and TCP access between them is slow and not reliable. loosing the ability to do things is bad)

Suggestion - John, shall we move this discussion to the VisionsOfTWiki?

-- SvenDowideit - 11 Sep 2003

Sven, you make some interesting points, some certainly resonate for me. At work we moved the contents of a Documentum system into TWiki and I've also played with database linking, mainly to document databases. I must admit though that I lack coherant ideas as to how TWiki could evolve in these areas.

BTW, have you seen FormFieldsPlugin, this allow more powerful forms (extra controls). I've also played a bit with how one could do some client side work flow using extra Plugin hooks - but, I didn't get anywhere useful.

-- JohnTalintyre - 12 Sep 2003

See FeatureTrackingInDocumentAndThreadMode, part of improving the workflow in Codev.

-- PeterThoeny - 22 Nov 2003

can we by any chance archive historical BugResolved topics? like ManageCgiScriptDev for example? I'd like to move them into a ResolvedBugs Web (that way they are still linked to from other topics). To my mind they are adding extra search hits to an already huge web.. (I'd like WebIndex to work here again too smile )

there mus be quite a large number of topics that are not relevant anymore - features that have been superceeded, Enhancement requests that have been implemented, and documented in other topics, etc..

-- SvenDowideit - 01 Dec 2003

I just read DisabledPluginsVarBroken for the first time a few hours back, and it got me thinking. We currently have over 100 open bugs in the TWiki bug-tracking system, and there's no way to tell at a glance how important fixes for them are. I think it's important enough that we should set up some kind of severity indicator in the WebForm, so that important bugs like this don't fall off of WebChanges and then proceed to being ignored like the other hundred-odd that are out there. I know it's hard to objectively judge a bug's severity, but I think with a few policy guidelines we could set up a system that would at least avoid protracted arguments over it.

-- WalterMundt - 14 Apr 2004

I'd like to bring up the idea of a BugsWeb using TWikiForms as WorkFlow (not using freeform text at all. This would be an opportunity to showcase TWiki's ApplicationServer abilities.

-- SvenDowideit - 14 Apr 2004

I say go for it. You've offered to set it up as a proof-of-concept as long as a year ago. You're now on the CoreTeam, and I think that if you have time it would be great to throw up a system, maybe migrate some existing bugs to it as samples. We can see where things go from there.

-- WalterMundt - 14 Apr 2004

Yeah, if we don't like it, we'll just refuse to use it, fill it full of garbage, and then make you move the entries back to The Old Way.

wink ...takes tongue out of cheek...

-- MattWilkie - 14 Apr 2004

A better bug tracking app certainly helps, especially to prioritize bugs. Rather then introduce a new web and worry about cross-linking, cross-web searches, stale webs, I suggest to continue to use the Codev web but with a specialized BugForm. That way we can easily reclassify content by choosing a different form, e.g. turn a bug into a feature request, etc.

-- PeterThoeny - 14 Apr 2004

Na Peter, I think thats part of the problem we have here. Polluting Codev with BugTopics makes it harder to see whats going on. I'd like to trial the TWikiBugWebApplication that I use at work - and then we can use Codev for actuall discussions, rather than workflow.

Also, having the PatternSkin will help (we actually, having the user customisable LeftBar is whats important) as this allowas better integration of information taht is spread across webs.

-- SvenDowideit - 15 Apr 2004

Nada Sven. Too many webs are bad for the health of the content. We are addressing growing content with restructuring, like TopicClassification, RelatedTopics and the recent CategoryCategories.

If we would move bug data to its dedicated web it will complicate reports like the ones in CairoRelease and CairoReleaseSummary. A BugTrackingAddOn can be created in a way that it can be deployed in any web with existing content. So we can have one bug database in Codev for TWiki core bugs and one in Plugins for Add-Ons/Plugins/Skin bugs. Like this, bugs are close to the "source of the problem" for easy cross-linking and reclassification.

-- PeterThoeny - 15 Apr 2004

as this is going to be my last attempt to convince you that you are wrong about this, I'll be breif.

  1. in the model i use, the BugsWeb is a TWikiForms only web, in which there is no %TEXT% area. this reults in an extremely database like system.
  2. this data is then queried and reported on in the discussion web
  3. the point of this is that when an issue is finished with, it does not pollute the discussion web
  4. WebChanges for the different functional datagroups are obvious, and Task assignment and tracking is more obvious too
The way it works at my workplace addressed successfully all the problems that I see with our current TaskTrackingSystem on TWikiDotOrg.

as far as "Too many webs are bad for the health of the content." goes - I'd call this an important issue that needs to be resolved irrespective of a Bug (or Task) tracking TWikiApplication, not a reason not to try it out.

btw, it actually simplifies report like the one on CairoRelease - I should know, those are direct simplifications of the TaskTracking work i have.

the biggest set of issues come about because in my workplace there is no security, the entire workflow is based on trust.

-- SvenDowideit - 15 Apr 2004

I was thinking about how Svens description above fits with what Peter said "I suggest to continue to use the Codev web but with a specialized BugForm. That way we can easily reclassify content by choosing a different form, e.g. turn a bug into a feature request, etc."

I was going to argue that it would mean that only the CoreTeam could reclassify topics as bugs by moving them to the bugs web (Because rename is locked down) but I realised that if it uses a form without a %TEXT% area then everyone would have to cut and paste to a new topic in the bugs web anyway, and refactor the original topic.

This would hopefully lead to better bug descriptions/reporting, and more refactoring of Codev content.

-- SamHasler - 15 Apr 2004

interesting workaround, but why not just enable rename? rename would empower the contributors to help refactor the whole wiki, not just bug-related topics.

-- WillNorris - 15 Apr 2004

It's hard to really evaluate an idea without being able to bang on it and see what falls off. For me it's hard anyway. How about Sven setting up what he's talking about so we can do a hands on test? If it really doesn't solve much we can always move the topics over to Codev.

The too many webs issue is (largely) orthagonal to this one. That problem is not how many containers there are, but how difficult it is to get pan-container views and linkages. Actually now that I think about it a bit more, what we are seeing with bug reports is the flip side of the coin. It is currently not easy enough to get sub-web slices. Our filters are inadequate.

We already have difficulties here. I don't think adding a form-only bug web will change this much. It's worth a trial I think.

-- MattWilkie - 15 Apr 2004

thanks to some IRC help that MS gave to someone else, I did what should have been obvious smile A query topic that will list all the topics that are assigned to a CoreTeamMember

for this I'd like parameterisd INCLUDES - and I need to use named INCLUDEs too smile

Warning: Can't find topic Sandbox.TWikiTopicsAssignedToUser

-- SvenDowideit - 02 May 2004

Discussion on the development model moved to PostCairoDevelopmentModel.

-- CrawfordCurrie - 02 Sep 2004

We need to consider how to handle PluginsBugTracking.

-- SamHasler - 11 Sep 2004

Moved from CairoRelease:

we should seperate the TopicStatus from TopicClassification.

if we have TopicClassification equal

  • Feature
  • Documentation
  • Patch
  • Bug
  • ...
and then have a TopicStatus that can be
  • Discussion / Proposal / Report (pick some word)
  • InProgress
  • Done
  • Rejected
  • ...
this should simplify our queries significantly

-- SvenDowideit - 22 Apr 2004

Edit | Attach | Watch | Print version | History: r66 < r65 < r64 < r63 < r62 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r66 - 2006-05-04 - SamHasler
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.