[Python-Dev] Small RFEs and the Bug Tracker

[Facundo Batista]

2008/2/22, Nick Coghlan <ncoghlan at gmail.com>:

>  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)

Fair enough.

There's missing one use case: how we mark an issue that is not such?
I'm talking about issues opened without an explanation, nothing saying
what is wrong, or which behaviour is strange or wrong for the original
poster, etc. Those issues that you want to answer "go back and learn
how to explain yourself".

Thanks!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/