#8: Decouple issue/response implementation from tracker

Contents

1. Motivation
2. Proposal
3. Implementation
4. Risks

Proposed by

Martin Aspeli

Proposal type

Architecture

Assigned to release

• Poi 2.0 (Unreleased)

State

being-discussed

Motivation

Decoupling issues/responses from the main tracker will allow alternative issue implementations to be used with the same basic UI and functionality.

Proposal

There are two parts to this - one easier than the other:

1. Make it easier to extend PoiIssue and use different issues with the tracker
   • Break PoiIssue into two - a mixin class with the fundamental schema, and a class adding the core "software tracker" functionality
   • Manage a registry of issue types, and allow the tracker creator to choose which issue type to use. The exact issue type would then be stored on the tracker. IConstrainTypes could be used to manage this under the hood.
   • Parameterise queries that explicitly reference PoiIssue
   • Modularise templates with macros and slots so that these can be more easily reused
2. Leverage Five/Z3's component architecture to decouple and componentise issues, responses and trackers
   • Most of the functionality associated with issues needs to be factored out into separate interfaces. The Z3/Five component architecture should then be used to provide appropriate adapters for custom issue types.

   (The specifics of how this would work have not yet been finalised.)

We have to decide whether to do both at once, or do this incrementally. My feeling is that unless option 1 is very easily done, it would be better to make all the refactoring happen at the same time.

In doing this, we should consider some of the scenarios which were originally their own proposals, but are probably better handled as examples of extending Poi through the work of this proposal. For example:

• The "pain point" tracker: Removing the notion of releases, but having issue deadlines with appropriate notifications when issues approach their deadlines.
• The "helpdesk" scenario, where you may want to submit some issues on behalf of others, keep track of additional contact information for the original submitter, mark some responses private, etc.
• An extensible tracker, where ATSchemaEditorNG is enabled on the issue type with the option of adding additional fields

I'm sure there are others as well.

Implementation

This is a work in progress

Let's consider some of the aspects of a tracker and how they may be expressed as interfaces:

For the tracker:

ITracker

The basics of issue tracking, includes the notion of managers, issue areas and types etc.

ISoftwareTracker(ITracker)

Extends the tracker to include version/release information and possibly other software-specific ideas

For issues:

IIssue

Basics of an issue: who submitted it, etc.

ISoftwareIssue(IIssue)

Adds specifics about software, e.g. discovered-in and target releases

IPainPointIssue(IIssue)

Specifics for "pain point" trackers, such as deadlines

IHelpDeskIssue(IPainPointIssue)

Specifics for help desk, e.g. original submitter etc.

Additional aspects of an issue and its responses may include:

IRespondable(IDiscussable)

Issues are discussable, and respones may be treated as issue discussion (try to re-use some of the existing pluggable discssion architecture here)

IResponseAction

A response may have involved some action, such as changing issue state, assignment etc. Adapt a response to IResponseAction to discover what this was.

INotifier

Issues should fire events when things happen. Event handlers should use INotifier to figure out who to notify and how, e.g. who to email, what text to send. (again, we should try to re-use existing architecture for this, or factor it out into a separate package if possible)

There are many specifics missing from this puzzle, but we should try to identify what behaviour and aspects exist today, and factor them into interfaces and adapters as much as possible. In doing so, we should experiment with supporting multiple issue types.

If this is to have any value, we must:

• Support the existing Poi use case without breaking everyone's instances. plone.org will still be the main user of this product!
• Show that it is possible to make non-software trackers work as Poi add-on modules. They should live in a separate product (and Poi may be factored into two - the base tracker and the software tracker we use today), and re-using elements of Poi must be painless and well-documented enough for this to be worthwhile.

Risks

The Archetypes vs. Five/Z3 story may not be mature enough yet to support this scenario.