Issue #18248 has been updated by jeremyevans0 (Jeremy Evans).


naruse (Yui NARUSE) wrote in #note-3:
> > * Stale Feature Requests can be closed
> 
> I'm unclear about this.
> I know some OSS projects introduce autoclose and it contributes the transparency of their issues.
> But unfortunately Ruby has many important but stale feature ideas for example namespace, macro-like something, defer, parser rewriting, and so on.
> I believe those feature requests shouldn't be closed...

Note that this isn't an autoclose (I really hate autoclose). With autoclose, there is no judgment involved from a committer.  In both the bug triaging and feature triaging guides, the committer is evaluating the issue and determining the appropriate course of action.

Stale feature requests would only be closed if:

* No committer indicates the feature is desired; *and*
* The committer doing the triaging believes the feature would not be desired.

In general, if there is doubt about whether the feature would be desired, the committer doing the triaging should not close it.  I can update the guide to make this more clear if you think it would help.

> > * Reopening Triaged Feature Requests
> 
> I roughly agree this, but I think it needs some discussion.
> * Why only Ruby developer can reopen it? (maybe the current permission only allows ruby commiters to reopen..)

My use of `Ruby developer` here means anyone who is contributing to Ruby, not just a committer. My intention here is that any Redmine user could reopen a feature request that was closed due to triaging, if they think the feature is valuable and @matz has not explicitly decided against it.  However, I'm not sure if the Redmine permissions allow that.  Maybe @hsbt knows?  If not allowed, maybe we can change it so any Ruby developer can request the issue be reopened, and any committer can reopen it if they think the feature may be desired.

> * guideline of forking feature requests sounds useful, but I think this is not feature triaging.

Agreed.  I just want to make sure people are aware that a decision made during triaging is not final, and can be easily reversed.  I can remove the section on submitting a new feature if desired.

----------------------------------------
Misc #18248: Add Feature Triaging Guide
https://bugs.ruby-lang.org/issues/18248#change-94112

* Author: jeremyevans0 (Jeremy Evans)
* Status: Open
* Priority: Normal
----------------------------------------
Ruby added a bug triaging guide in June 2019, and since then I've used it to reduce the number of open bugs in the tracker from over 1400 to about 300.  Ruby currently has over 1200 open feature requests on the issue tracker. From a cursory review, many of these have already been implemented, and many are unlikely to be desired.  I would like to add a feature triaging guide to Ruby and start triaging feature requests, with the goal of having open feature requests be features not yet implemented that the Ruby core team would like implemented or would consider patches for.  By doing so, we can make it easier for potential contributors to Ruby to easily see possible contributions they could make.

I've added a pull request with a draft of the proposed guide: https://github.com/ruby/ruby/pull/4953



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

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