CollectorStatuses

This page serves to document the full meaning of the various possible statuses for issues in the Zope Collector.

There is discussion about other possible meanings of these states, possible future states and other changes to the Collector at CollectorStatusesAlt. However, until that discussion is resolved, please respect the meanings below when dealing with issues.

Please only put an issue into a status if you are sure it meets the criteria below.

Pending

These are new issues that have been submitted but are not currently assigned to anyone. They may have had plenty of activity or no activity at all. In either case, they will need further attention.

Accepted

This means that someone has read the issue and accepted that it has real merit as either a feature request or as a genuine bug report.

The issue may need further discussion and/or time to implement the required changes.

Accepted issues will have an assigned supporter. If you wish to work on this issue, the assigned supporter(s) should be contacted. If the assigned support cannot be contacted, please either assign yourself to the issue if you're collector staff, or add comments stating that you're working on the issue if you're not so someone who is collector staff can come along and modify the issue state as appropriate.

Rejected

These are issues that have been read and assessed as not requiring changes to the Zope core. If the issue requires more information to be investigated, please use the Deferred state rather than the Rejected state.

Common reasons may be:

• The issue is not with a Zope Core component but with a third party components such as a database adapter, Plone, etc. The rejector should advise the submitter of the appropriate place to go to resolve their problem. "hell" is not an appropriate place ;-)
• The issue cannot be reproduced. This means the rejector has checked that there is a test for the reported behaviour and written one if one is not present, demonstrating that the problem the submitter reported does not occur.
• More information was requested from the submitter but none was forthcoming within a month of more information being requested. See there Deferred state below.

NB: Please only reject issues as a last resort, it's disheartening for the submitter and premature rejection can mean bugs are missed and hang around longer as a result.

Resolved

This means the changes required by the bug or feature requested have been implemented, along with any required tests.

Tests are always required, unless they are impossible to write. Slight leniency may also be granted where you're making a minor change that would require spending major amounts of time because the code you're making the minor change to has no tests whatsoever.

When you resolve an issue, please include:

• what action was taken
• what branches of which respositories any code was committed to
• the expected version(s) of Zope where the changes will land.

Deferred

This status has one specific use. It is used when a bug report is unclear or has been in a pending state for a long time and more information has been requested from the submitter.

Items should be left in the Deferred state no longer than 1 month, after which they should be handled as for Pending if the submitter has supplied the requested information, or Rejected otherwise, asking the submitter to open a new issue if they experience the problem further.

Wontfix

This means that the bug or feature request the issue refers to has been accepted as valid but will not be dealt with for the forseeable future.

Reasons for this may include:

• Bugs in deprecated components of Zope.
• Bugs where there is no solution but a common workaround which means the bug should never be excercised.
• Features that don't have a champion and so are unlikely to be implemented.
• Changes that don't fix a bug or add a new feature, and don't have a champion, or haven't see activity in a long time.
• Changes that would be sensible to make, but would cause more damage than good. eg: Would break backward compatability, are hard/impossible to test or would make it harder to test other things.

NB: A valid bug in a non-deprecated Zope component should never be wontfix'ed. Likewise, issues should not be wontfix'ed simply because they haven't seen action is a while.

JUST SO IT'S CLEAR: Only use wontfix as a last resort!