History for TrackerAndWorkflow

??changed:
-
  Status: Initial discussion phase

  Currently the Tracker has a fixed workflow (see
  "workflow note":#workflownote ) 

  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 <a name="#keytraits">key traits</a> (see also a
    discussion in <a href="SeriousUserInterfaceNiggles#keytraits">
    !SeriousUserInterfaceNiggles</a>) 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.

  *<small><a name="workflownote">The essence of tracker fixed workflow
  is captured in 
  <a href="../SoftwareCarpentry/!TrackerDiagrams.html#issue_stage">an
  issue-stage state diagram</a>, and in a much more elaborate (and
  somewhat ad hoc)
  <a href="../SoftwareCarpentry/!TrackerDiagrams.html#issue_lifecycle">
  issue-lifecycle diagram</a>.</a></small>

  Owner: KenManheimer<br>
  Last major update: May 7, 2000