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


My turn!

I'll go point-by-point through the proposal.

1. Ruby Design Council

I like the idea of a central group through which feature discussions must pass. I do not support these discussions being closed or limited to members of that group.

My view is that this group is more to clarify the responsibilities of Ruby implementers rather than to ensure features are designed well. The latter would be a result of a good council, but the most important aspect here is getting new features or feature changes air time with important stakeholders.

Normal users are as important as council members, as matz says...but normal users and implementers have different responsibilities. A new feature may or may not affect a normal user, but ideally it should make them happier in the future. A new feature definitely affects all implementers, and ideally should not make them sadder. The council should be a mechanism to ensure that doesn't happen...not a mechanism to control the future of Ruby.

2. Proposals must be submitted by council members

Debatable, but not a bad idea. It would help guarantee council members are given the opportunity to weigh in (note I say opportunity here...any design committee needs to have a mechanism for abstaining). I'd say proposals can come from anywhere, but the council is gatekeeper (along with matz) for what would eventually be considered "standard".

3. Proposal criteria: English, complete, with RubySpecs

Not Japanese? Most of the folks implementing Ruby speak Japanese as their first language. If we're giving priority to implementers, the primary language should be Japanese.

Of course that's not tractable either. English is a good common language. I think the goal should be that all proposals are in English when they go to the council, but eventual docs should be in both English and Japanese. This might need to include RubySpec; have you (Brian) given any thought to localizing specs?

Requiring that an incoming proposal be complete is also intractable. Most of the issues of a proposal won't get fleshed out until discussed and implemented. It's not possible to cover every angle of a feature without discussion, and may not be possible without at least a reference impl. This has to be an organic, iterative process.

Requiring complete RubySpecs before implementation is also intractable. For a feature like refinements, how many hundreds of lines of specs would we need to write, never knowing if they're even valid until someone implements it? Again, this needs to be organic and iterative. RubySpecs or similar should be a required final artifact of the process, but it can't be a prerequisite for starting the process.

Brian does say in his longer description that he doesn't intend to stymie experimentation in the impls, and this process is not intended to stop impls from trying out feature ideas before proposing them.

4. Council members have veto power

I find the whole veto discussion offensive. We have been working on JRuby longer than any other alternative implementation, and never have I felt like matz didn't do the right thing when presented with the facts. I believe the council should have great weight in the decision to include or reject a feature, but we do not own Ruby. We are also biased; new features mean new work for us, so I have often fought the tendency to oppose any changes whatsoever. Our role is to help individual feature proposals evolve, not to control Ruby's evolution.

The council is to me more like a commission; a group of users responsible for accepting or making proposals, discussing and researching them thoroughly, and then making a recommendation upstream. That seems like the right model for Ruby.

5. All council members must implement approved features

Obviously we'll all want to be compatible with the "standard", but having this be a prerequisite to getting a feature into MRI ignores the fact that we all have resource constraints. Consider that no current implementation has fully implemented 1.9 features, and even JRuby -- the closest so far -- is still catching up. Should the process force us to drop everything and implement Ruby 2.1 features before we finish 1.9 or 2.0 work, just to allow those features to get into 2.1?

6. Discussion begins

This is completely unreasonable. At this point, you have required that the proposal be completely written up, with full specs (before any implementation starts and before the council sees the proposal), with implementations by all council members...all BEFORE discussion of the feature begins? This would require all implementations to implement half-baked features just to get them on the agenda. Do we really want a waterfall process for Ruby design?

Organic process...iterative...etc. Implementation (in a reference impl perhaps), discussion, and specification need to go hand-in-hand.

7. Final vote with veto privileges

Same comments as for #4.

--

Other concerns:

Requiring some new application to be written for this process to start is unreasonable. Can you provide an estimate for how long it will take to build such an app? Personally, I'd be happy with a new Redmine top-level project on MRI's install that we can follow (to go along with "ruby trunk", we'd have a "ruby design"). I am also not opposed to email and live discussions. I think the wiki-based "current view of the feature plus comments" is absolutely necessary. I do not see a need for a new app to be written, and I think waiting for such an app could derail the whole thing.

Honestly, since getting more involved in MRI's Redmine, it feels like it has everything we need. We just need to split off feature discussions and take better advantage of its project management features.

A separate mailing list would really help me, and for this process I think it's a must. Many to most discussions in ruby-core are specific to MRI (and I have been keeping up with all discussions for several weeks now).

I do not feel like RubySpec should be the sole language in which incoming proposals are tested, but I do feel like we should limit it. RubySpec would be preferred, but RSpec and test/unit should also be acceptable. It should be the responsibility of the council to see that RubySpecs get written during the process (perhaps by requiring it of the proposer).

I would like to see RubySpec governance expanded to the council members. No one member should control RubySpec if it is intended to become the one true standard Ruby compliance, or we're no better off than with MRI's test/*.

More to come as I ponder ramifications.
----------------------------------------
Feature #7549: A Ruby Design Process
https://bugs.ruby-lang.org/issues/7549#change-34674

Author: brixen (Brian Ford)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


Matz,

At RubyConf 2012, I gave a talk about a design process for Ruby (http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-design-for-ruby). So far, over 12,000 people have viewed that talk. I think it is reasonable to say that many people are concerned about and interested in a design process for Ruby.

On Monday, we had an IRC meeting of Ruby implementers. Most of the points in my proposal were discussed but I'm concerned that a lot of confusion remains.

I have written a post that describes a Ruby design process and hopefully clarifies points that people found confusing:

http://brixen.io/2012/12/11/a-ruby-design-process

I would like to propose this process for making changes to Ruby. I am going to put a summary of the process at http://rubyspec.org/design and ask for people who support the process to submit their signature. I'd like to request that you consider the response from the community for my proposal.

Thank you,
Brian



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