Topic: wftk -- Usage scenarios: Open-source software project

wftk home ] [ usage scenarios ] [ discussion ]
The simple workflow I came up with as something exemplifying an open-source project is oriented toward bug fixes and patches rather than a big release all at once. Given the roles Requester, Analyst, Developer, Tester, and Documentation writer, consider the following workflow:
  1. Requester fills out a form and requests a change (either bug fix or enhancement request).
  2. Analyst studies the request and categorizes it.
  3. Developer makes the change.
  4. Tester tests the change in isolation and in the system (regression testing, whatever).
  5. Documenter makes necessary changes to documentation.
(2/21/00) XML process definition here.

As most people can tell you, this is already more organized than many projects. (If only every project had a documenter!) The flow is very linear, so there's not much point in drawing it: it simply goes from one step to the next, and no step may be completed before the previous step is finished. Very simple but it brings up some interesting questions nonetheless.

As more people become involved in the change (the project) then more people need to be notified as to progress. It would be useful in this case, for instance, for the documenter to receive all notifications as soon as the documenter has been assigned. My original paper RAD for this workflow show notification boxes going everywhere. It doesn't always make sense to have to specify notification; in this case, it's useful to consider each member of the project group as being in a mailing list as soon as they join. Then notifications simply go to the list.

Other messaging
The original RFP does mention something about message archiving, if I recall correctly (although I may have made that up in my head). During such a project, there will be considerable back-and-forth between analyst and developer, analyst and requester, developer and requester, and so forth. Again, I could set those up as explicit negotiation paths, but it makes more sense to include this sort of thing in a list as well. The conclusion would seem to be that workflow engines would benefit from including mailing list facilities.

Certainly there needs to be some way for mailings to be archived. This could be as simple as including an archival daemon in the mailing list so that messages are saved. I would think the deliverable repository would be the most appropriate place to store archived messages (including negotiations.)

Process environment
A more important insight I had while putting this scenario together is: what happens if the analyst gets two request which are essentially the same change? Or what if a naive requester puts two changes into one request? In the first case, it makes sense for the two processes to be merged, and in the second it makes sense for the single process to be split into two processes.

More generally, processes need to be understood to be running in the greater context of a workflow system. Processes may need to interact in more sophisticated ways (although I'm not sure exactly how yet.) Certainly the following relationships between processes must exist:

  • Processes must be able to merge
  • A process must be able to split
  • A process must be able to initiate another process This is just logical. At some point in a process, some state may hold which triggers the initiation of a second process. In this case, the first process then continues normally. I can't think of many good examples yet: one might be that too great a delay in the completion of a task may trigger an administrative review process.
  • A single task in a process must be able to stand for another entire subprocess
    Again, this is necessary for the concept of compound processes, but we're going to see some really interesting things along these lines.

What have we learned?

  • Notification should be specifiable either on the individual task level (as an explicit box) or in some global way across the entire process. These specifications may be mixed in a single process.
  • Some kind of message-handling system would be nice.
  • Interaction between processes must be possible. Processes do not execute in a vacuum.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.