home contents changes options help subscribe

last edited 8 years ago by ZifNab

Problem: Establish an evolutionary replacement for the zope collector

We need to quickly develop a replacement for the Zope collector, and would like to develop one that can serve as foundation to evolve into a full-featured, versatile issue tracker.

Background

We have been aiming for a while to replace the Zope Collector with a more comprehensive (like the the Zope Tracker, http://www.zope.org/Members/klm/TrackerWiki/FrontPage ) and also more easily extensible facility. The recent unexpected loss of the existing collector ( http://lists.zope.org/pipermail/zope-dev/2001-September/013090.html ) has forced our hand, requiring quick production of some replacement.

Rather than doing the most expedient thing, however, we would like to approach this in a way that will reduce the effort to migrate to a more comprehensive solution, at some later date. It looks like we can get ease of immediate implementation plus ease of eventual migration by going with a CMF-based solution, with some eye towards evolution to a more substantial implementation at a later date.

Overarching Goals

  • Have the replacement in production relatively very soon.
  • Have it provide at least the functionality that the collector did
  • Maximize ease of migration path to a later, more comprehensive solution

(We will also need to provide for migration of old collector issues to the new collector, in so far as the old issues can be recovered.)

Solution

This combination of goals paints a poster-child portrait of a candidate CMF application.

  1. Bug/issue tracking seems like a model content management issue.
  2. The CMF provides for rapid development of such applications while facilitating easy customization and easy extension of cosmetic aspects like look and feel and UI layout, as well as deeper dimensions like workflow. Applications implemented as CMF content inherently gain ease of use as well as easy interoperation with other CMF content types.
  3. Further, a CMF-based approach is ultimately our preferred candidate for the long-term solution, and it's likely that a CMF-based short term version will ease the migration to a CMF-based long term version.
  4. The impending migration of zope.org to a CMF foundation clinches aiming for the CMF as the new collector's platform practically a no brainer.

Specific Goals and Objectives

Here's the desired functionality, grounded by what the collector does:

Goal: Enable anyone to submit issues
Anyone can submit requests (for bug fixes, new features, and documentation enhancements/additions).
  • Objective: Enable the requester to specify issue characteristics, and capture automatically self-evident ones (like the identity of the supporter, if they're logged in).

    Metadata covers requester identification, issue classification and characterization, and so forth. See the Issue Scheme section, below, modelled after the collector schema.

  • Objective: Enable requesters to include file uploads with issues.

    (This is for patches and related artifacts. It may make sense to allow anyone to add artifacts to an existing issue - it's less likely to be exploited for abuse than other things, since supporters are notified any time something an issue is changed, and so would be more likely to be alerted than other targets of opportunity.)

Goal: Enable anyone to examine existing issues
Enable visitors to browse the collection and find specific issues according to specific criteria.
  • Objective: Provide a search interface, by which visitors can search on the salient characteristics, including issue classification, content, workflow status, and so forth.
  • Objective: Provide for search sortings the ease supporters common modes of working through issues. (We need to determine what those modes are.)
  • Objective: Provide bookmarkable searches (form get method)
Goal: Enable supporters to register their handling of an issue
Use issue instances to contain the details of the responses to the issue, as well as the details of the request. Thus, at any moment they represent the current disposition of the issue, a record of the actions taken, who took them, and so forth.
  • Objective: A supporter adds a response to an issue. The response may just be a note about something in the issue, or a change in the status of an issue (see the Issue Schema current_status field.) Any change in the status sends notifications to the supporters and the issue requester (if they registered their email address in submitting the issue).

    ![I am thinking about both simplifying the requirements and extending the scope by enabling anyone, not just designated supporters, to add a response to an issue. This would make the new collector more susceptible to mischief, but i don't have the impression that was a problem in the past, and it would make it easier for community members to chime in, and even resolve miscellaneous issues.]

    The transcript of an issue is simply document with successive comments, each appended when a new action is taken.

  • Objective: Enable supporters only to edit the transcript document.

    This is a safety for handling mischief, to be used only in extraordinary circumstances. The ordinary mode should be to take an action, and append comments.

  • Objective: Enable supporters to make an issue invisible, and/or delete artifacts from an issue.

    Another safety, for mischief. Deletion of artifacts could be an action offered only to supporters from a skinned-folder interface.

Goal: Actively alert concerned parties to issue additions and changes
Use email to notify supporters and requester about issue activity.
  • Objective: Send out email notification whenever a change is made to an issue. If the requester included their email address, include them in the email.

Issue Schema

Here's the issue schema i propose, based on that of the old collector but with some adjustments: 

      issue_id
      requester, email
      date_submitted, date_modified
      title
      description
      product:                Zope, Collector, Database, Catalog ZServer, 
      classification:         bug feature doc
      security_related
      importance              1,2,3,4 (change to high, medium, low)
      assigned_to
      current_status:         Pending, Accepted, Completed, Rejected, Postponed
      status_description
      reported_version
      other_version_info

Changes from old collector schema:
  • Ommitted many choices from current_status - expecting they will be explained in status_description, when necessary: 
              Rejected: Cannot be Reproduced, Duplicate, Forgotten, Retracted,
                    Superceded, Unsupported, We don't know how to do it
          Accepted: Ongoing
          Pending: Pending (security), Pending (working), Under Consideration,
                   Wish)
  • Added status_description, for qualifications to status, eg particularly reason for rejection.
  • Removed urgency (i don't think the distinction from importance is clear enough, or that supporters pay it attention - but i could be convinced otherwise)
  • Added other_version_info - we can suggest including the following pieces of info when relevent: browser version, webserver version, os, python version, database type and version, etc.

Brian (Sep 14, 2001 12:50 pm; Comment #1)
This generally looks good to me. One thing missing is some sort of "security-related" flag like the old collector had.

That allows us to screen potentially security issues from search results until they have been assessed, and also serves as a sort of "top priority" flag that we use internally (and soon community committers will use) to make sure those issues get immediate attention.

  • klm, 09/18/2001 - Good point. The CVS dump i had didn't include that field, so i didn't even know about its existence. I've included it in the schema, and will incorporate the contingency in the use cases...
ZifNab? (Oct 6, 2001 10:06 am; Comment #1)
Concerning the assigned to field: Would it be possible to make it so that an issue can be assigned to another person etc... but that an history of these people is kept? If I look at our department I see that for instance a problem is assigned to Person A, but this person says that it is better for Person B so moves the problem to B. When B worked on it, he saw that at a certain moment he tried everything and the only solution was to move it to C. C solved the problem. So we've had a chain of responsible people, but they all worked on certain times on the problem. It would be nice to see that in a tracker as well.