2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>: > 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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
