Tracker Diagrams

This document contains supplemental diagrams for my Software Carpentry Tracker proposal, plus some exposition describing them. The collection of documents includes mostly use cases plus a few issue lifecycle state diagrams:

• Overarching Use Cases, exhibiting the overview of the activities plus all the actors
• Issue Correspondence Use Cases
• Tracker Management Use Cases
• Rules Use Cases
• Issue Stage State Diagram
• Issue Lifecycle State Diagram

This diagram acts as a map into the specific use case diagrams for the tracker, presenting an overview of the tracker activities, the Actors, and indicating the corresponding subdiagrams. Just below this diagram i'll describe the Actors.

• Anyone - 'Anyyone' is a pseudo actor, denoting any of the other actors plus the catchall 'anonymous' one. The point is that any of the actors can, eg, submit an issue or browse the collection of them.
• Requester - An issue's Requester is person who submitted it. In open trackers, anonymous visitors can peruse and submit issues. In dedicated trackers, only designated members can visit the tracker.
• Subscriber - A member who elected to be among those notified about issue postings.
• Supporter - A member selected by the tracker administrator to be among those in the loop on the handling of issue. Supporters are notified about the arrival of new issues, they can take responsibility for handling of issues by 'accepting' them - thereby becoming the IssueOwner, and they have reserved privileges for changing issue stage and viewing private issues.
• IssueOwner - Supporters who have accepted issues become owners of those issues. Multiple supporters may accept an issue, so there can be multiple owners.
• TrackerOwner - The member who created the tracker (or another member delegated the responsibility by the tracker creator), privileged to configure the tracker and responsible for directing handling of neglected issues.
• Scheduler - A system actor responsible for running the rules associated with the tracker.

This diagram shows the central activities of the tracker, participants correspondence in an issue. Along with just posting more info about an issue, just about all actions with respect to the issue are conducted through submission of new messages.

This diagram shows the tracker administrator's management activities.

This diagram shows the prospective rules that can affect the disposition of an issue according to changes in its stage, passage of time (like those with supporter responses past due), and so forth.

This diagram presents the legitimate stage transitions an issue can take. See also the subsequent diagram, which tries to convey more specifics about the issue lifecycle.

Like the last one, this diagram also presents the legitimate stage transitions an issue can take. It adds specifics about the issue situations, and also indicates the Actor roles and their changes accompanying particular actions. (This diagram probably betrays standard UML practices, in well-intentioned but perhaps misguided ways...-)