[ruby-core:84133] [Ruby trunk Feature#4963][Closed] Refine and Document the Issue Tracking Process

Issue #4963 has been updated by mame (Yusuke Endoh).

Status changed from Open to Closed

I'm closing this ticket since it is not about ruby's feature.  I think it should be discussed at ruby-core mailing list.

----------------------------------------
Feature #4963: Refine and Document the Issue Tracking Process
https://bugs.ruby-lang.org/issues/4963#change-68239

* Author: lazaridis.com (Lazaridis Ilias)
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: Next Major
----------------------------------------
=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




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>