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

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

[Lazaridis Ilias]

Issue #4963 has been reported by Lazaridis Ilias.

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

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

[Yui NARUSE]

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

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

[Lazaridis Ilias]

Issue #4963 has been updated by 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, ...)



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

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

[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

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

[Lazaridis Ilias]

Issue #4963 has been updated by 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.




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

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

[Lazaridis Ilias]

Issue #4963 has been updated by Lazaridis Ilias.


=begin

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

=end

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

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

[Yui NARUSE]

Issue #4963 has been updated by Yui NARUSE.


We want a documentation which prevents people who don't read previous discussion
even if we show a reference to the discussion.
----------------------------------------
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

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

[Lazaridis Ilias]

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

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

[Lazaridis Ilias]

Issue #4963 has been updated by Lazaridis Ilias.


An issue type "Task" would be helpful (sometimes its simply a task which is filed).
----------------------------------------
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

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

[mame (Yusuke Endoh)]

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

Target version set to 3.0


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

Author: lazaridis.com (Lazaridis Ilias)
Status: Open
Priority: Normal
Assignee: 
Category: Project
Target version: 3.0


=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://bugs.ruby-lang.org/

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

[mame]

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/