Feature #4963

Refine and Document the Issue Tracking Process

Added by Lazaridis Ilias almost 4 years ago. Updated about 3 years ago.

[ruby-core:37732]
Status:Open
Priority:Normal
Assignee:-

Description

=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

History

#1 Updated by Yui NARUSE almost 4 years ago

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.

#2 Updated by Lazaridis Ilias almost 4 years ago

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

#3 Updated by Nobuyoshi Nakada almost 4 years ago

Hi,

At Sat, 2 Jul 2011 17:33:26 +0900,
Lazaridis Ilias wrote in :

  • Possibly rename "bug" to "defect".

I prefer to keep it than the less familiar word.

--
Nobu Nakada

#4 Updated by Lazaridis Ilias almost 4 years ago

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.

#5 Updated by Lazaridis Ilias almost 4 years ago

=begin

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

=end

#6 Updated by Yui NARUSE almost 4 years ago

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

#7 Updated by Lazaridis Ilias over 3 years ago

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.

#8 Updated by Lazaridis Ilias over 3 years ago

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

#9 Updated by Yusuke Endoh about 3 years ago

  • Target version set to Next Major

Also available in: Atom PDF