Facundo Batista wrote:
First two definitions of "resolve" from the American Heritage dict:
- To make a firm decision about.
- To cause (a person) to reach a decision.
I think it applies quite well.
It only tells you that a resolution was reached, not what that resolution was.
"Resolution: resolved" is meaningless repetition - what matters is *how* the issue was resolved, and simply saying 'resolved' doesn't tell anybody that. 'Fixed', 'accepted', 'invalid', 'rejected' , etc are resolutions since they give you some idea of how the issue was resolved - the only thing missing is a definition of just how they should be used.*
Now, dropping 'later', 'postponed' and 'remind' from the list of available resolutions is something I could wholeheartedly support. If we want to postpone something to a later release, we should put an appropriate entry in the version list.
My stab at definitions for the other resolutions:
# Feature request resolutions accepted - feature request accepted (possibly via attached patch) rejected - feature request rejected
# Bug report resolutions fixed - reported bug fixed (possibly via attached patch) invalid - reported behaviour is intentional and not a bug works for me - bug could not be replicated from bug report out of date - bug is already fixed in later Python version wont fix - valid bug, but not fixable in CPython (very rare)
# Common resolutions duplicate - same as another issue (refer to other issue in a comment)