Issue #8271 has been updated by headius (Charles Nutter).


duerst (Martin Dürst) wrote:
>  I wanted to oppose a more formal process because I think it's 
>  unnecessary overkill, but reading the proposal, I can't really see much 
>  in terms of more formality, so I think the title of this proposal should 
>  be changed to reflect that. (Sorry if I missed something.)

I agree. This is more a cosmetic change. But I think it's an important one.

It also feels to me like it would be easier to clean up gaps in the current process (not strictly formalize, but tidy up) if we had a separate feature tracker.

>  That was the case before we had the CommonRuby project, as Yui has shown.

Correct. They're just interspersed with bugs that are MRI-specific, making it harder to know which issues alternative implementers should track.

>  Comparing
>  
>  trunk (bugs and features)
>  2.0.0 (backport)
>  1.9.3 (backport)
>  1.9.2 (backport)
>  ...
>  
>  and
>  
>  New feature
>  Bug  trunk
>        2.0.0 (backport)
>        1.9.3 (backport)
>        1.9.2 (backport)
>        ...
>  
>  it's indeed quite possible that the later is easier to understand and 
>  follow.

Indeed. The former throws features in alongside MRI-specific details. That's wrong, in my mind.

>  I think this is only feasible if it can be automated. One way to 
>  automate it is to add feature numbers to tests, but I'm not sure if this 
>  will work well.

The fact that all items in Redmine are numbered the same is possibly confusing here. I don't imagine it would be hard to add a separate "Feature ID" field to redmine, allowing a simple report of features that have been accepted.

There are many JSRs and PEPs that never see the light of day, but overall the JSR and PEP processes have their own numbers assigned to things.

>  > I believe this process is no more complicated than the current process.
>  
>  I agree. It's mainly about people getting used, and if it's possible to 
>  move issues around between projects, then it's not too bad if there are 
>  a few mistakes from time to time.

That is indeed a key point. The fact that Redmine supports different bug schemas in the *same* project makes me believe it should be just as trivial to move a bug to CommonRuby (as a feature) as it is to flip the feature toggle now.

Again, mostly a cosmetic change, but an important one: we're making it known that Ruby feature changes are a top-level concern...not a mixed-priorty concern stirred in with MRI bugs.

>  > 4. Further justification
>  >
>  > A lot of noise has been made over the past several months about Ruby lacking a process for new and changing features.
>  
>  I'd rather prefer Ruby to be the best language with a "lacking" process 
>  than the language with the best process.

Agreed. I feel like the current process works...it's just hard to follow with MRI bugs and Ruby features in the same place.

>  > The design process proposed by Brian Shirai (née Ford)
>  
>  [That should be "(né Ford)" because the former would be grammatically 
>  female (see http://en.wikipedia.org/wiki/Name_at_birth).]

Thanks! I went out on a limb using that word for the first time.
----------------------------------------
Feature #8271: Proposal for moving to a more visible, formal process for feature requests
https://bugs.ruby-lang.org/issues/8271#change-38604

Author: headius (Charles Nutter)
Status: Assigned
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: 
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 feature change all implementations will need to consider implementing, I propose that we move all feature requests into a separate Redmine project. I see the following benefits to this arrangement:

* Features are always in one place. One-stop-shopping for implementers to track changes to "Ruby" that are not specific to MRI.
* No confusion about where feature requests should be filed. Currently, people usually file feature requests against "trunk", but sometimes against version-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 to 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 features could have an "approved by matz" field. We could also have other metadata tracking other implementations, such as "approved by implementations" or "affects implementations" with drop-downs for known impls. One-stop-shopping to know whether a given impl is affected and/or has agreed to add the feature.
* More visible process for folks in the community that can't follow the current 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 "feature" in the current tracker), issues would be filed directly in CommonRuby. Discussion proceeds exactly as the current process, perhaps with additional issue fields added that allow tracking matz approval, etc, as stated in §1.

Issues that are approved for a Ruby version will have fields/metadata to indicate 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 feature added (just saying 1.9.3p400 is insufficient since the feature does not 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 changes, those issues would be tranferred into CommonRuby at the point where it'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 pages about the CommonRuby project. The "feature" value in current "trunk" project could either be removed (after migrating features to CommonRuby) or modified 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 development 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 lacking a process for new and changing features. The design process proposed by Brian Shirai (née 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 kicked around on ruby-core, but the truth is that there *is* a current process, even if it's not particularly visible. By implementing my proposal, the process would become more obvious and transparent without major impact to MRI'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-strict process) changes to "Java" independent of individual JVM implementations. 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 lack visibility into that process and in many cases fails to provide tools to non-MRI implementations to participate. Moving feature requests and discussion 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.


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