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

On 2013/04/16 5:35, headius (Charles Nutter) wrote:
>
> Issue #8271 has been reported by headius (Charles Nutter).
>
> ----------------------------------------
> Feature #8271: Proposal for moving to a more visible, formal process for feature requests
> https://bugs.ruby-lang.org/issues/8271

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

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


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

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


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

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.


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

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.


> 3. Detriments

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

I agree that this is mostly a documentation issue.


> * More complex process.
>
> 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.


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


> 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).]


> gained some measure of popularity,

A very modest measure as far as I understand, and quite a bit of 
well-founded opposition, too.


> but requires a complete retooling and reworking of current processes, making it infeasible for short-term implementation.

And also has some very serious shortcomings, such as "specify everything 
completely before implementing anything", which makes it infeasible even 
in the long term.


Regards,    Martin.