Feature #4963: Refine and Document the Issue Tracking Process

• Status: Closed
• Assignee: -
• Target version: 3.0

[lazaridis.com (Lazaridis Ilias)]

=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

[naruse (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.

[lazaridis.com (Lazaridis Ilias)]

Yui NARUSE wrote:
[...]

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

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

(just a few notes to "specifications")

The issues relate usually all to "specifications":

defect : issue subjecting a violation of the specifications
feature : issue subjecting an extension of the specifications
limitation: issue subjecting the limitation of an implementation (to comply to the specifications)
rubyspecs : issue subjecting the specification itself (e.g. missing spec, defect spec, ...)

[nobu (Nobuyoshi Nakada)]

Hi,

At Sat, 2 Jul 2011 17:33:26 +0900,
Lazaridis Ilias wrote in [ruby-core:37732]:

• Possibly rename "bug" to "defect".

I prefer to keep it than the less familiar word.

--
Nobu Nakada

[lazaridis.com (Lazaridis Ilias)]

Yui NARUSE wrote:

Lazaridis Ilias wrote:
[...]

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

You're possibly right here.

Status: Open, Assigned, Accepted, Closed, Rejected

I think changing "Reject" to some friendly name is better.

Possibly "Negated" is the friendlier word.

[lazaridis.com (Lazaridis Ilias)]

=begin

See #5034 as a negative example: rejecting issue in the middle of a conversation.

=end

[naruse (Yui NARUSE)]

We want a documentation which prevents people who don't read previous discussion
even if we show a reference to the discussion.

[lazaridis.com (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.

[lazaridis.com (Lazaridis Ilias)]

An issue type "Task" would be helpful (sometimes its simply a task which is filed).

[mame (Yusuke Endoh)]

• Target version set to 3.0

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