CollectorStatusesAlt

![This is an alternative framing of CollectorStatuses. The most important differences are in the conception of Accepted, Wontfix, and Deferred, but there are also significant differences in Pending and Rejected.]

This page describes the intent of each status for issues in the Zope Collector.

Please be clear about the statuses before you use them!

Pending

Issues awaiting assignment or settlement. They may have comments and other accumulated history, but are, essentially, awaiting handling.

Accepted

Issues that have at least one supporter who has taken the responsibility for their solution. The supporter is responsible for either solving the issue or collecting further information to determine what resolution it deserves.

(People interested in helping with the resolution of an accepted issue - or any issue, for that matter - but not official supporters can signal their intention by posting a comment to the issue.)

Rejected

Issues assessed to be outside the collector's scope or otherwise invalid, and settled with no further action.

Common reasons for rejection:

• The issue is not with a Zope Core component but with a third party components such as a database adapter, Plone, etc. The rejecter should indicate the appropriate venue for the issue, when known. ("Hell" is not an appropriate venue ;-)
• The issue cannot be reproduced. The rejector should establish that there is a test, if feasible, demonstrating that the reported behaviour does not occur, writing one if necessary.
• More information was necessary and requested, but was not provided within a reasonable period (typically a month).

NB: Issue rejection should be done carefully. You should be confident that rejection is warranted, and emphatically avoid abusing the submitter, whatever the quality of the report. Bug reports benefit the Zope community as a whole, and even mistaken reports constitute a potential contribution. The submitters next report may be more useful, particularly if supporters avoid discouraging them, and also make some effort to clarify what would have worked better in the current one. Dismissing valid bug reports, or course, sacrifices valuable opportunities to improve the system.

Resolved

The bug has been fixed or requested feature implemented, along with any required tests.

Tests are always required, unless they are impossible to write. Leniency may be warranted for very minor changes?

When you resolve an issue, please include details about:

• the action taken
• the repository branches where code was committed
• the expected Zope version(s) where the changes will land.

Deferred

Issues that are valid but have been put on hold until some later occasion.

The occasion may be when more supporter time is expected to be available for issues of that type, or when other features or fixes that would facilitate solution of the issue are expected to have landed.

Deferred can also be used for valid issues that are observed to be languishing in the "Pending" state, and on the countdown for moving to "Wontfix" (if ultimately judged to be valid but lacking sufficient interest) or "Rejected" (if unfixable due to lack of sufficient information).

Wontfix

This means that the bug or feature request the issue refers to is recognized as legitimate, but rectifying the bug would unacceptably betray backwards compatability.

Other reasons for the Wontfix status include:

• Bugs in deprecated components of Zope.
• Bugs where there is a common and sufficient workaround, and a real fix is not feasible or not worth the effort.
• ? Features that don't have a champion and evidently (according to the amount of time the issue has languished) aren't important enough to anyone who could implement them. ? ![Not sure about this one. Others might suggest using "Deferred" for this purpose, instead, or maybe "Rejected". This needs to be settled.]

As with rejecting an issue, use "wontfix" carefully and gently!