From: Lazaridis Ilias Date: 2011-07-21T15:25:20+09:00 Subject: [ruby-core:38317] [Ruby 1.9 - Feature #4963] Refine and Document the Issue Tracking Process Issue #4963 has been updated by Lazaridis Ilias. Yui NARUSE wrote: > We want a documentation which prevents people who don't read previous discussion > even if we show a reference to the discussion. Mr. Naruse, I'm sorry, I could not understand this comment. ---------------------------------------- Feature #4963: Refine and Document the Issue Tracking Process http://redmine.ruby-lang.org/issues/4963 Author: Lazaridis Ilias Status: Open Priority: Normal Assignee: Category: Project Target version: =begin Based on the experiences with some issues, especially #4893, I would like to suggest the following: * The issue-tracking process should be refined and documented. The goal is to avoid misunderstandings and to make involved parties (developers, contributors, users, ...) feel better during interaction. A few thoughts to consider (can be used as a foundation for a document draft): * An issue remains "Open", until it is resolved. * Rejecting an issue means "closing" it. * An issue of type "bug" cannot be closed, until the bug is fixed. * The status "Rejected" for a bug report means essentially "the bug does not exist" (= workforme) * If an issue contains [PATCH] in the title, and the patch cannot be applied, then ask the author first for a revision, prior to "rejecting". * Prefer to place feature requests on future releases, instead of rejecting them. * An issue (even a defect/bug) can be postponed (e.g. to version 1.9.x or 2.0) * Some issues need several steps until they are solved in production quality and the author may use the issue-tracker to collect feedback and test results. A patch should not be "rejected" with the status, as this would close the issue. Some issues about the Issue-Tracker: * Introduce Tracker "Limitation", thus issues which are not exactly bugs but limitations (e.g. #4893, known limitation of current implementation) can be tracked. * Introduce Status "Retracted", thus the issue author/reporter can say "I retract the issue", e.g. after understanding that he made a mistake. This would be much friendlier against the author/reporter. * Find a replacement for the term "Rejected" (it just sounds a little bit "harsh"). * Possibly rename "bug" to "defect". =end -- http://redmine.ruby-lang.org