TrackerAndWorkflow

Status: Initial discussion phase

Currently the Tracker has a fixed workflow (see workflow note )

Flow Path Elaboration

Some tracker users need to incorporate twists in issue lifecycle, like requiring test department validation after a supporter has obtained a bug fix, before the issue can be closed. (Brian Brown's company has specifically requested it.) Support organizations may wish to institute policies that dictate, for instance, the point at which an issue counts against the requester's quota of issues - like, upon acceptance by a supporter, or maybe only after the requester signs off on completion. These are just a few of the prospectively useful elaborations of an issue's flow path - some parameterized workflow framework is necessary to provide even moderately flexible accomodation for the possibilities.

Issue Assignment

As Stephen Harrison has pointed out, tracker issues get supporters on a "pull" basis - the supporters accept the issues. In some cases it makes sense for issues to be "pushed" onto certain supporters - or at least, onto select groups of supporters.

The tracker's current arrangement of including particular supporters among those receiving notifications about the issues according to association of the supporters with sets of trait values provides some functionality along these lines, albeit in a very limited fashion. One of the limitations is in the ways that the conditions for traits can be constructed - only simple or composition is available. Another limitation is that the only thing affected is notification - no actual obligations are imposed, and there is no impact on, eg, searches by supporters for issues. More elaborate trait conditions and some kind of inbox-like searches may be in order.

(Some kind of inbox architecture may make sense, and suggests tiered inboxes, with first-line and second-line support, etc. Federated trackers may provide the right direction for approaching that, however.)

Trait Sensitivity

It makes lots of sense to continue having workflow sensitive to issue attributes, including tracker-configurable traits (as the issue notifications already are), like urgency and due-date. We may want to institute that by identifying key traits (see also a discussion in SeriousUserInterfaceNiggles) and values, and enabling tracker administrators to designate their own trait names and values to map to these key traits.

As with some of the EmailReception considerations, with a bit of effort some moderately general workflow provisions could be quite useful as common Zope facilities for organizing workflow across document objects.

*The essence of tracker fixed workflow is captured in an issue-stage state diagram, and in a much more elaborate (and somewhat ad hoc) issue-lifecycle diagram.

Owner: KenManheimer
Last major update: May 7, 2000