[Zope-Coders] Re: July Bug Day Roundup
Ken Manheimer
klm at zope.com
Thu Aug 12 17:23:38 EDT 2004
Sounds like nobody objects to "Suspend" and "Pending" as i framed them.
Cool.
Here's three more, leaving the two most controversial (and the idea of
providing for automatic expiration) for later. I'll be out of the office
and away until monday, so will continue my part in the discussion then.
Good weekend, all!
"Assigned" (instead of "Accepted")
Issues that have at least one supporter responsible for their
solution. This is the state for issues that are being worked on or are
awaiting complete assessment for their viability depending on further
input from the submitter.
The assigned supporters are responsible for either solving the issue or
collecting further information to determine what resolution it deserves.
Supporters are assigned to issues either by "accepting" them or via
"assignment" by another supporter or collector manager. Supporters can
resign from the issue, but the issue will automatically move back to
"Pending" if that leaves it with no supporters.
(People interested in helping with the resolution of an accepted issue -
or any issue, for that matter - but lacking official supporter privileges
can signal their intention by posting a comment to the issue.)
"Resolved"
The fix or feature has been implemented, along with any necessary tests.
Tests which would provoke the bug, if it were still present, and/or
demonstrate the correctness of the new functionality 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:
o the action taken
o the repository branches where code was committed
o the expected Zope version(s) where the changes will land.
"Rejected"
Issues assessed to be invalid for this collector, so that they will not
be addressed any further.
Common reasons for rejection:
o The issue is outside the scope of the collector. For the Zope
collector, this means the issue is not with a central Zope component,
but rather a third-party item such as a database adapter, Plone,
etc. The rejecter should indicate the appropriate venue for the
issue, when known.
o 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.
o More information was necessary to assess the issue, and it was
requested, but was not provided within a reasonable period (typically
a month).
> "Submitted"
>
> This is the state for things that are completely unhandled. Comments
> move "Submitted" issues to "Pending", and once out of "Submitted" issues
> generally do not return there. (Until we discover a compelling reason
> to recirculate issues back, they don't return here.)
>
> "Pending"
>
> Issues that have been handled (have comments and/or other actions) but
> are still awaiting substantial disposition (assignment or settlement).
>
> Issues _can_ return here if they got into a being-handled or closed
> state but then lost that progress. Eg, something that was assigned to a
> supporter, but then the supporter had to bail out and no other
> supporters could take it on. Or something that was mistakenly settled,
> but has no supporter to take its responsibility and so has to be
> returned to an awaiting-disposition state - "Pending" is it.
Ken
klm at zope.com
More information about the Zope-Coders
mailing list