[ruby-core:92120] [CommonRuby Feature#8271] Proposal for moving to a more visible, formal process for feature requests

Issue #8271 has been updated by ashag (Asha Goyal).


Yes, It's good if we see a better report page.

https://www.jealousme.com/category/earphones/?filter_brand=3Dsoundpeats

----------------------------------------
Feature #8271: Proposal for moving to a more visible, formal process for fe=
ature requests
https://bugs.ruby-lang.org/issues/8271#change-77446

* Author: headius (Charles Nutter)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: =

----------------------------------------
Proposal for moving to a more visible, formal process for feature requests.

1. Introduction

In order to make it clear that an issue or change to MRI is a visible featu=
re change all implementations will need to consider implementing, I propose=
 that we move all feature requests into a separate Redmine project. I see t=
he following benefits to this arrangement:

* Features are always in one place. One-stop-shopping for implementers to t=
rack changes to "Ruby" that are not specific to MRI.
* No confusion about where feature requests should be filed. Currently, peo=
ple usually file feature requests against "trunk", but sometimes against ve=
rsion-specific projects. It's also valid to say that a feature improvement =
or clarification is not specific to trunk. Tracking features separate from =
"trunk" and version-specific Redmine projects keeps the process localized t=
o one Redmine project.
* Ability to add fields to "feature" issues that do not have relevance for =
"bugs". For example, bugs do not usually need approval from matz, but featu=
res could have an "approved by matz" field. We could also have other metada=
ta tracking other implementations, such as "approved by implementations" or=
 "affects implementations" with drop-downs for known impls. One-stop-shoppi=
ng to know whether a given impl is affected and/or has agreed to add the fe=
ature.
* More visible process for folks in the community that can't follow the cur=
rent process or don't believe there's a process in place.

I propose that the project be called CommonRuby (already created and under =
some use) and be a top-level entry on bugs.ruby-lang.org.

2. Processes

For issues that are obviously new features (i.e. user knows to select "feat=
ure" in the current tracker), issues would be filed directly in CommonRuby.=
 Discussion proceeds exactly as the current process, perhaps with additiona=
l issue fields added that allow tracking matz approval, etc, as stated in =
=A71.

Issues that are approved for a Ruby version will have fields/metadata to in=
dicate at which version the feature is available. This may mean specifying =
multiple releases if, for example, 2.0.1 and 1.9.3p400 would both see a fea=
ture added (just saying 1.9.3p400 is insufficient since the feature does no=
t exist in 2.0.0. This avoids having to track features through the backport=
 process to know if there are multiple releases that contain the feature.

For issues that start out as bugs, but later become features or feature cha=
nges, those issues would be tranferred into CommonRuby at the point where i=
t's obvious they're feature-related.

3. Detriments

Benefits are stated in the introduction above.

Possible detriments with mitigation:

* Confusion by users about where to file features.

This would be mitigated by adding more information to bug-related home page=
s about the CommonRuby project. The "feature" value in current "trunk" proj=
ect could either be removed (after migrating features to CommonRuby) or mod=
ified to error/warn or switch the issue to CommonRuby programmatically.

* More complex process.

I believe this process is no more complicated than the current process. It =
also makes the process of evolving "common Ruby" more isolated from MRI dev=
elopment and may make it easier for users to track that evolution.

4. Further justification

A lot of noise has been made over the past several months about Ruby lackin=
g a process for new and changing features. The design process proposed by B=
rian Shirai (n=E9e Ford) gained some measure of popularity, but requires a =
complete retooling and reworking of current processes, making it infeasible=
 for short-term implementation. Other process-change proposals have been ki=
cked around on ruby-core, but the truth is that there *is* a current proces=
s, even if it's not particularly visible. By implementing my proposal, the =
process would become more obvious and transparent without major impact to M=
RI's development or Ruby's evolutionary processes.

5. Prior art

The PEP (Python Enhancement Proposal) and JSR (Java Specification Request) =
processes are partial inspiration for this proposal. The latter governs all=
 visible feature changes to Python independent of bug reports to the main "=
CPython" implementation. The latter governs (through a heavy and overly-str=
ict process) changes to "Java" independent of individual JVM implementation=
s. Both processes have been very successful at isolating spec changes from =
implementation changes, although the JSR process tends to move very slowly =
and be less transparent than it should be.

6. Conclusion

Ruby does not lack a process for adding or changing features, but it does l=
ack visibility into that process and in many cases fails to provide tools t=
o non-MRI implementations to participate. Moving feature requests and discu=
ssion to a CommonRuby project independent of MRI will make the process more=
 transparent and easier to follow (for users and implementers) while having=
 minimal impact on the current process.



-- =

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

Unsubscribe: <mailto:[e-mail]?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>