From: "naruse (Yui NARUSE)" Date: 2012-12-21T16:56:51+09:00 Subject: [ruby-core:51030] [ruby-trunk - Feature #7549] A Ruby Design Process Issue #7549 has been updated by naruse (Yui NARUSE). headius (Charles Nutter) wrote: > 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. I felt this is straightforward one. Ruby Design Process by brixedn didn't explicitly show its goal, but I think its goal is to ease make a MRI compatible implementation. > The latter would be a result of a good council, As far as I understand, a council is not for good design but for consensus and compromise. It sometimes causes bad design because of compromise. > but the most important aspect here is getting new features or feature changes air time with important stakeholders. MRI has Release Engeneering process, and you'd read mame's announce "2.0.0 feature freeze". http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/48191 This is the air time with all 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. So what you want is a council for implementers, right? And the goal for the council is to prevent adding a feature which is hard to implement, I guess. > 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". If this council is for implementers, it sounds reasonable. > 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? If the goal of the council is written above, the language should be off course English. > 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. I think brixen's process is inspired by W3C HTML/CSS's process. Seeing their process, a proposal should be comming with its implementation. And after discussion and with some another implementations, it becomes a concreate spec. > 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. I think so. brixen's process is not based on current/real development model. It will prevent Ruby developing or simply ignored. > 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. I'm glad that you think so. > 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. It sounds like an Executive Commitee of the Java Community Process (JCP). http://jcp.org/en/participation/committee Its goal seems different from brixen's proposal. > 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. I setup a new project. https://bugs.ruby-lang.org/projects/common-ruby ---------------------------------------- Feature #7549: A Ruby Design Process https://bugs.ruby-lang.org/issues/7549#change-34925 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/