Issue #18248 has been updated by naruse (Yui NARUSE).


> * Already Implemented Feature Requests should be closed
> * Feature Requests That Would Probably Not Be Considered can be closed
> * Newly Requested Features must not be closed unless Matz or maintainer explicitly rejected it

I agree these. I think those principle are right and it follow the current operation.

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

> * 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..)
* the description which notes "when you reopen, you should add something new" sounds reasonable
* guideline of forking feature requests sounds useful, but I think this is not feature triaging.


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

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