[ruby-core:37735] [Ruby 1.9 - Feature #4963] Refine and Document the Issue Tracking Process

Issue #4963 has been updated by Yui NARUSE.


Lazaridis Ilias wrote:
> * An issue remains "Open", until it is resolved.

There is "Assigned" and "Feedback".

> * Rejecting an issue means "closing" it.

Yes, if the author of the ticket doesn't think the ticket can be closed, they can reopen 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)

What is the difference between bugs and features is difficult problem.
Spec level issue like #4893 can't be say simply a bug.

> * 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".

Yeah, it should be "Feedback" before "Reject",
but if there is a bug or a reasonable feature the ticket's life won't depend on the patch.

On ruby, the spec is prior to a patch; even if the patch is valid, the patch will be rejected if the behavior it introduces is wrong.

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

Agree.

> * 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.

The issue tracker is not one's work space or studying room, it should handle issues.
If you want to concrete a feature request which is half baked, it should be discussed on ruby-talk or ruby-core.

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

It should be "Feature"; difference between limitation and feature is difficult, I don't think it should be separate.
"Bug" and "Feature" are different because "Bug" should be fixed as soon as possible.
(so we don't want to increase low priority bugs)

> * 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").

Adding more status makes tracking difficult.
I think changing "Reject" to some friendly name is better.

> * Possibly rename "bug" to "defect".

I can't comment this.
----------------------------------------
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