wiki:TicketProcess

Version 1 (modified by ieslick, 8 years ago) (diff)

--

Process

Here is a simple policy and procedure for using TracTickets

  • Tickets should be submitted with neither version nor release fields filled out
  • The critical/major/minor field can be used to indicate urgency relative to the ability to use the program
  • The defect vs. enhancement will help us triage tickets when time is scarce. A bad API decision is not a defect, neither is some piece of ODB semantics that we missed. Defects are failures in documented functionality.
  • After ticket submission, the developers will evaluate, assign and schedule work as appropriate
  • Users can then submit comments about the ticket and/or volunteer to fix the problem themselves

Any reports of defects should provide example code and the version or code date against which the problem occurred as well as lisp version and platform run against. Please be specific! Requests for feature enhancements should motivate the feature with example code, the problem it would solve, etc.

Rationale

We do not use the version field as we don't have a version on which we plan to do long term patch-oriented maintenance. This may change in the future, in which case tickets against older versions make sense. For now, problems that arise get fixed on the development branch and included in the next release. Back patches may be provided on a one-of basis if circumstances call for it.

Our roadmap is tracked by release milestones and tickets against those milestones. A review of all tickets ordered by milestone will give you a sense of our long term plans. See View Tickets in menu bar for access to reports.