[CMF-checkins] CVS: CMF - Configuration.stx:1.1 CorrespondentAddsNote.stx:1.1 Installation.stx:1.1 Lifecycle.stx:1.1 NotificationStrategy.stx:1.1 Overview.stx:1.1 SkinningCMFTracker.stx:1.1 SubmitterDescribesIssue.stx:1.1 SubmitterGuide.stx:1.1 SubmitterRequestsResolution.stx:1.1 SupporterAcceptsIssue.stx:1.1 SupporterClosesIssue.stx:1.1 SupporterGuide.stx:1.1 SupporterRedirectsIssue.stx:1.1 SupporterRejectsIssue.stx:1.1 WorkflowTransitionLogging.stx:1.1
tseaver@digicool.com
tseaver@digicool.com
Sat, 2 Jun 2001 02:43:15 -0400 (EDT)
Update of /cvs-repository/CMF/CMFTracker/help
In directory korak.digicool.com:/tmp/cvs-serv29413/help
Added Files:
Configuration.stx CorrespondentAddsNote.stx Installation.stx
Lifecycle.stx NotificationStrategy.stx Overview.stx
SkinningCMFTracker.stx SubmitterDescribesIssue.stx
SubmitterGuide.stx SubmitterRequestsResolution.stx
SupporterAcceptsIssue.stx SupporterClosesIssue.stx
SupporterGuide.stx SupporterRedirectsIssue.stx
SupporterRejectsIssue.stx WorkflowTransitionLogging.stx
Log Message:
- Initial cut: documentation and skeleton only.
--- Added File Configuration.stx in package CMF ---
Configuring CMFTracker Instances
Properties
Title --
Descriptive name for the tracker, used in dropdowns, etc.
Description --
Longer textual description of the kinds of issues managed
by this tracker.
--- Added File CorrespondentAddsNote.stx in package CMF ---
"Correspondent Adds Note to an Issue" Use Case
Actors
- Correspondent (may be a Submitter or on of the tracker
owners)
Goal
- Add a comment which illustrates or helps in the resolution
of an "in-work" issue.
Preconditions
- Correspondent is authenticated WRT the CMFSite.
- or more issues has already been
"accepted":../SupporterAcceptsIssue.stx by one or more
Supporters into a tracker.
- Correspondent is authorized to add content to an issue
within a given tracker (has either "Submitter" or "Owner"
role WRT the issue).
Main Flow
1. Correspondent either receives notification of (e.g., via a
nightly email) or browses to (e.g., via a slashbox) the
list of issues in which she is involved, either as the
Submitter or as a Supporter.
System displays a summary listing of all issues which are
in a "non-closed" state (e.g., "pending acceptance", "in
work", "pending verification", etc.); these issues are
filtered such that those requiring action by Correspondent
(based on their state, and Correspondent's roles), are
grouped at the top of the list; others group to the
bottom.
2. Correspondent clicks through to an issue, and selects its
"Reply" action.
System prompts for the reply, which may reference other
content objects via standard HTML/STX linking.
3. Correspondent fills out the reply and submits it.
System creates a DiscussionItem within the issue, using the
data supplied by Correspondent.
System "notifies":../NotificationStrategy.stx all of the
issue's Correspondents of the new reply.
See Also
- "Overview":../Overview.stx
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Supporter Accepts Issue":../SupporterAcceptsIssue.stx
- "Supporter Redirects Issue":../SupporterRedirectsIssue.stx
- "Supporter Rejects Issue":../SupporterRejectsIssue.stx
- "Supporter Closes Issue":../SupporterClosesIssue.stx
- "Tracker Issue Lifecycle":../Lifecycle.stx
- "Notification Strategy":../NotificationStrategy.stx
--- Added File Installation.stx in package CMF ---
Installing CMF Tracker
Installing the Product into Zope
1. Unpack the tarball and copy / link the CMFTracker
directory into the Products directory of the INSTANCE_HOME
(preferred) or SOFTWARE_HOME.
*Note that this product depends on having a current
installation of the CMFCore and CMFDefault products.*
2. Restart Zope, and verify that the product has installed
correctly by checking the Products folder in the Control
Panel.
Registering Tracker with CMFSite
1. Create an ExternalMethod in the CMFSite instance, using
the following parameter values:
- ID: install_tracker
- Title: Install CMFTracker
- Module name: CMFTracker.Install
- Function name: install
2. Run the method from the 'Test' tab. Note that it creates
new type objects (for 'Tracker' and 'TrackerIssue') and
registers a new skins directory.
Creating a Tracker Instance
1. From the 'folder_contents' view of the site, or of one of
its folders, select the "New" button; select the
"Tracker" radio button and supply an ID for the new
tracker. Click the "Add" button.
2. Fill out the metadata for the tracker (see "Configuring
CMFTracker Instances":../Configuration.stx).
--- Added File Lifecycle.stx in package CMF ---
Tracker Issue Lifecycle
States
Unsubmitted -- The "larva" state, in which the submitter has
begun to describe the issue, but has not yet completed the
description and submitted it to a tracker.
Pending Acceptance -- The "pupa" state, in which no supporter
in the target tracker has yet accepted or rejected the issue.
In Work -- At least one supporter has accepted the issue.
Rejected -- A supporter has rejected the issue; it can no longer
be considered open, nor should it be revived.
Resolved -- One of the supporters assigned to the issue has
completed all work related to the issue, which is now "closed"
Deferred -- One of the supporters has determined that the issue
cannot be dealt with during the current phase of the project;
it is marked closed, but can be revived later.
Diverted -- A supporter has determined that the issue either
duplicates another issue, or will be resolved by the same
effort required to resolve the other; the issue shows up
as a dependency of the original.
--- Added File NotificationStrategy.stx in package CMF ---
Tracker Notification Strategy
Problem
People who create or resolve tracker issues need to be able
to find *their* issues quickly, and know what actions they
are to perform on them.
Alternatives
- Create "slashbox"-style views which query the tracker or
trackers a person is interested in, showing the issues in
which they have a stake.
- Have each tracker create a daily email summary, showing
responsibility and status of each open issue, including
clickable URLs.
--- Added File Overview.stx in package CMF ---
CMFTracker Overview
Goals
- Allow site members to view, search, and create content related
to issues using the same tools and techniques used to with
other CMF content.
- Provide a migration target for existing "Collector",
http://classic.zope.org:8080/Collector
and "Tracker",
http://www.zope.org/Members/klm/Tracker
issues.
Use Cases
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Supporter Accepts Issue":../SupporterAcceptsIssue.stx
- "Supporter Redirects Issue":../SupporterRedirectsIssue.stx
- "Supporter Rejects Issue":../SupporterRejectsIssue.stx
- "Correspondent Adds Note to Issue":../CorrespondentAddsNote.stx
- "Supporter Closes Issue":../SupporterClosesIssue.stx
Design Notes
- "Tracker Issue Lifecycle":../Lifecycle.stx
- "Notification Strategy":../NotificationStrategy.stx
- "Workflow Transition
Logging":../WorkflowTransitionLogging.stx
Administrator Guide
- "Installing CMFTracker":../Installation.stx
- "Configuring CMFTracker":../Configuration.stx
User Guide
- "Submitter's Guide":../SubmitterGuide.stx
- "Supporter's Guide":../SupporterGuide.stx
Developer's Reference
- "Skinning CMFTracker":../SkinningCMFTracker.stx
--- Added File SkinningCMFTracker.stx in package CMF ---
Skinning CMF Tracker
Hmm, how shall we start?
--- Added File SubmitterDescribesIssue.stx in package CMF ---
"Submitter Describes Issue" Use Case
Actors
- Submitter
Goal
- Describe an issue to be discussed / resolved by the team
assigned to its category.
Preconditions
- Submitter is authenticated WRT the CMFSite in which she
wishes to create an issue.
- Submitter is authorized to create IssueDescriptions in the
location where she is browsing the site.
Main Flow
1. Submitter initiates content creation (e.g., by selecting
the "New" button from a 'folder_contents' view) and
supplies the required constructor parameters
(typically, ID and type, as prompted for in the
'folder_factories' form).
The site creates a new IssueDescription object in that
location and redirects to its initial view, which may be
customized on a site-by-site basis.
2. Submitter edits the IssueDescription, potentially linking
it to other content via standard HTML/STX mechanisms.
Submitter may make multiple edits to the IssueDescription.
and need not "submit it for
resolution":../SubmitterRequestsResolution.stx immediately.
The IssueDescription would not normally be "discussable"
(nor even "public") while in this "larval" phase.
See Also
- "Overview":../Overview.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Supporter Accepts Issue":../SupporterAcceptsIssue.stx
- "Supporter Redirects Issue":../SupporterRedirectsIssue.stx
- "Supporter Rejects Issue":../SupporterRejectsIssue.stx
- "Correspondent Adds Note to Issue":../CorrespondentAddsNote.stx
- "Supporter Closes Issue":../SupporterClosesIssue.stx
- "Tracker Issue Lifecycle":../Lifecycle.stx
- "Notification Strategy":../NotificationStrategy.stx
--- Added File SubmitterGuide.stx in package CMF ---
Submitters' Guide to CMF Tracker
Concepts
- "Tracker Issue Lifecycle":../Lifecycle.stx
Use Cases
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Correspondent Adds Content to
Issue":../CorrespondentAddsContent.stx
--- Added File SubmitterRequestsResolution.stx in package CMF ---
"Submitter Requests Issue Resolution" Use Case
Actors
- Submitter
Goal
- Request that an issue be resolved by the team assigned to
its category.
Preconditions
- Submitter is authenticated WRT the CMFSite in which she
wishes to create an issue.
- Submitter has previously "created an
IssueDescription":../SubmitterDescribesIssue.stx in the
location where she is browsing the site, and now desires
to submit it to the group who will evaluate and resolve it.
Main Flow
1. Submitter browses to an existing IssueDescription object
for which she has "Owner" local role.
2. After reviewing the issue, Submitter selects its "Submit"
action. The system prompts Submitter to designate the
"target" Tracker (if this designation has not already been
made); it then "logs a workflow
transition":../WorkflowTransitionLogging.stx to the
"Pending Review" state, and catalogs it such that the
owners of the target Tracker are
"notified":../NotificationStrategy.stx of its submission.
At this point, the IssueDescription is not generally
"discussable" (although workflow transitions can create
replies); nor is the issue "public" while in this
"pupal" phase.
See Also
- "Overview":../Overview.stx
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Supporter Accepts Issue":../SupporterAcceptsIssue.stx
- "Supporter Redirects ISsue":../SupporterRedirectsIssue.stx
- "Supporter Rejects ISsue":../SupporterRejectsIssue.stx
- "Tracker Issue Lifecycle":../Lifecycle.stx
--- Added File SupporterAcceptsIssue.stx in package CMF ---
"Supporter Accepts Issue" Use Case
Actors
- Supporter
Goal
- Take responsibility for an issue submitted to a given
tracker.
Preconditions
- Supporter is authenticated WRT the CMFSite, and is
authorized to accept issues into a tracker.
- One or more issues has already been
"created":../SubmitterDescribesIssue.stx and
"submitted":../SubmitterRequestsResolution.stx to that
tracker.
Main Flow
1. Supporter receives notification that one or more issues
are pending against a tracker for which she is
responsible (e.g., by email, or by a topic-like slashbox).
Supporter browses to that tracker and selects the "Review
pending issues" action.
System displays a summary listing of all issues which are
in "pending acceptance" state.
2. Supporter clicks through to an issue, reviewing it, and
selects the "Accept" action.
System prompts for a log message.
3. Supporter supplies the log message and confirms acceptance.
System **moves the accepted issue into the tracker**,
renaming it and readjusting ownership and role mappings to
accomodate the "tracker issue lifecycle":../Lifecycle.stx.
In its original place, system creates a TrackerTicket, a
Favorite-based pointer to the newly-moved Issue. Supporter
becomes the new owner of the issue; Submitter retains
"Submitter" local role.
System "notifies":../NotificationStrategy.stx Submitter and
tracker owners of the acceptance of the issue.
At this point, the issue becomes
"discussable":../CorrespondentAddsNote.stx by both the
submitter and by the owners of the tracker into which it
has been accepted.
See Also
- "Overview":../Overview.stx
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Supporter Redirects Issue":../SupporterRedirectsIssue.stx
- "Supporter Rejects Issue":../SupporterRejectsIssue.stx
- "Correspondent Adds Note to Issue":../CorrespondentAddsNote.stx
- "Supporter Closes Issue":../SupporterClosesIssue.stx
- "Tracker Issue Lifecycle":../Lifecycle.stx
- "Notification Strategy":../NotificationStrategy.stx
--- Added File SupporterClosesIssue.stx in package CMF ---
"Supporter Closes Issue" Use Case
Actors
- Supporter
Goal
- Mark an issue submitted to a given group as "closed".
Preconditions
- Supporter is authenticated WRT the CMFSite, and is
assigned to a tracker.
- One or more issues has already been
"accepted":../SupporterAcceptsIssue.stx by a supporter.
Main Flow
1. Supporter either receives notification of (e.g., via a
nightly email) or browses to (e.g., via a slashbox) the
list of issues for which she is responsible.
System displays a summary listing of all issues which are
in a "non-closed" state (e.g., "pending acceptance", "in
work", "pending verification", etc.); these issues are
filtered such that those requiring action by Correspondent
(based on their state, and Correspondent's roles), are
grouped at the top of the list; others group to the
bottom.
2. Supporter clicks through to an issue, reviewing it, and
selects one of the "terminal" actions ("Resolve", "Defer",
"Divert", "Reject").
System prompts for a log message.
3. Supporter supplies the log message an confirms the action.
System updates the issue, notifying all involved
correspondents that it has been closed. At this point,
no further "discussion":../CorrespondentAddsNote.stx of
the item is possible.
See Also
- "Overview":../Overview.stx
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Supporter Accepts Issue":../SupporterAcceptsIssue.stx
- "Supporter Redirects Issue":../SupporterRedirectsIssue.stx
- "Supporter Rejects Issue":../SupporterRejectsIssue.stx
- "Correspondent Adds Note to Issue":../CorrespondentAddsNote.stx
- "Tracker Issue Lifecycle":../Lifecycle.stx
- "Notification Strategy":../NotificationStrategy.stx
--- Added File SupporterGuide.stx in package CMF ---
Supporters' Guide to CMF Tracker
Concepts
- "Tracker Issue Lifecycle":../Lifecycle.stx
Use Cases
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Correspondent Adds Content to
Issue":../CorrespondentAddsContent.stx
- "Supporter Accepts Issue":../SupporterAcceptsIssue.stx
- "Supporter Rejects Issue":../SupporterRejectsIssue.stx
- "Supporter Redirects Issue":../SupporterRedirectsIssue.stx
- "Supporter Closes Issue":../SupporterClosesIssue.stx
--- Added File SupporterRedirectsIssue.stx in package CMF ---
"Supporter Redirects Issue" Use Case
Actors
- Supporter
Goal
- Assign issues submitted to the wrong tracker to a more
appropriate one.
Preconditions
- Supporter is authenticated WRT the CMFSite, and is
authorized to accept issues into a tracker.
- One or more issues has already been
"created":../SubmitterDescribesIssue.stx and
"submitted":../SubmitterRequestsResolution.stx to that
tracker.
Main Flow
1. Supporter receives notification that one or more issues
are pending against a tracker for which she is
responsible (e.g., by email, or by a topic-like slashbox).
Supporter browses to that tracker and selects the "Review
pending issues" action.
System displays a summary listing of all issues which are
in "pending acceptance" state.
2. Supporter clicks through to an issue, reviewing it;
determining that it would be more appropriately submitted
to another tracker, Supporter selects its "Redirect" action.
System prompts for a log message and for the new target
tracker.
3. Supporter selects the new target, supplies the log message
and confirms the redirect.
System "logs a workflow
transition":../WorkflowTransitionLogging.stx to the
"Pending Review" state, and catalogs it such that the
owners of the new target Tracker are
"notified":../NotificationStrategy.stx of its submission.
(Submitter and "old" target tracker owners should be
notified, as well).
See Also
- "Overview":../Overview.stx
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Supporter Accepts Issue":../SupporterAcceptsIssue.stx
- "Supporter Rejects Issue":../SupporterRejectsIssue.stx
- "Correspondent Adds Note to Issue":../CorrespondentAddsNote.stx
- "Supporter Closes Issue":../SupporterClosesIssue.stx
- "Tracker Issue Lifecycle":../Lifecycle.stx
- "Notification Strategy":../NotificationStrategy.stx
--- Added File SupporterRejectsIssue.stx in package CMF ---
"Supporter Rejects Issue" Use Case
Actors
- Supporter
Goal
- Reject submitted issues which are not "well-formed", or for
which the target tracker's owners are not responsible.
Preconditions
- Supporter is authenticated WRT the CMFSite, and is
authorized to accept issues into a tracker.
- One or more issues has already been
"created":../SubmitterDescribesIssue.stx and
"submitted":../SubmitterRequestsResolution.stx to that
tracker.
Main Flow
1. Supporter receives notification that one or more issues
are pending against a tracker for which she is
responsible (e.g., by email, or by a topic-like slashbox).
Supporter browses to that tracker and selects the "Review
pending issues" action.
System displays a summary listing of all issues which are
in "pending acceptance" state.
2. Supporter clicks through to an issue, reviewing it, and
selects its "Reject" action.
System prompts for a log message.
3. Supporter supplies the log message an confirms rejection.
System logs a "workflow
transition":../WorkflowTransitionLogging.stx to the
"Private" state.
System "notifies":../NotificationStrategy.stx Submitter
and tracker owners of the rejection of the issue.
See Also
- "Overview":../Overview.stx
- "Submitter Describes Issue":../SubmitterDescribesIssue.stx
- "Submitter Requests Issue
Resolution":../SubmitterRequestsResolution.stx
- "Supporter Accepts Issue":../SupporterAcceptsIssue.stx
- "Supporter Redirects Issue":../SupporterRedirectsIssue.stx
- "Correspondent Adds Note to Issue":../CorrespondentAddsNote.stx
- "Supporter Closes Issue":../SupporterClosesIssue.stx
- "Tracker Issue Lifecycle":../Lifecycle.stx
- "Notification Strategy":../NotificationStrategy.stx
--- Added File WorkflowTransitionLogging.stx in package CMF ---
Workflow Transition Logging
Each workflow transition (e.g., from "private" to "pending review",
or from "in work" to "resolved"), adds both a "workflow
history" entry (standard CMF mechanism) *and* a "reply" to the
issue, where the reply is populated with the contents of the
log message entered by the actor.
This reply will be "decorated" with the name of the target
workflow state. For example, when a Supporter
"closes an issue":../SupporterClosesIssue.stx as "Resolved",
the reply would look like::
<<Resolved>>
<Body of log message goes here.>