From: "enebo (Thomas Enebo)" Date: 2012-12-13T01:39:55+09:00 Subject: [ruby-core:50836] [ruby-trunk - Feature #7549] A Ruby Design Process Issue #7549 has been updated by enebo (Thomas Enebo). I consider this process to be way over the top. I can appreciate most of Brian's observations about problems in our process, but I really don't like the proposed solutions. At the very least I feel like incrementally chipping away at our primary communication issues will have a decent payoff. For any process created, I primarily would like: 1. Reasonably detailed proposal with at least one implementation (implementation may lag original proposal to get feedback before starting) a. corner cases must be enumerated to best of ability b. consideration of how it can affect different implementations should be discussed in proposal points a and b are not required to be perfect because a submitter obviously may not think of all corner cases or may not be able to actually know how all Rubies are implemented. This is ok provided that the proposal is created well in advance of its approval and deployment as a new feature of Ruby. "created well in advance" is vague because not all features require the same level of scrutiny or time to digest. 2. Some amount of regular implementer meetings to make sure all implementations are well aware of new proposals. This is also a place to talk about the many outstanding gaps between the Ruby implementations. As a part of process an Agenda item should eternally exist to cover new and existing proposals, so that issues can be exchanged. At this point I would not go much further until we refine what a proposal for #1 is and use it/improve it (starting it Aarons example of wiki entry might be a good starting place). And see how much more process miscommunication improves by having #2 in place. Language communication is another issue which is difficult. I think it is totally unreasonable for non-English speaking Japanese to be asked to learn to speak English if they want to continue being involved in Ruby. It is a laughable and a totally unrealistic suggestion (learning a new language takes years of serious effort). People suggesting this should really consider how insulting this is to people who have been working on Ruby for 10+ years. They made this language useful for us in the first place! Let's please try and find better middle ground (like getting some corporate sponsorship to help do 2-way translation or even a volunteer effort perhaps). Our implementers meetings have been in English with some translation by ebi and asarih, but we can hopefully get more communication from the Japanese-only developers at these meetings. I can see why this is a difficult problem, but it certainly is not an impossible problem. ---------------------------------------- Feature #7549: A Ruby Design Process https://bugs.ruby-lang.org/issues/7549#change-34671 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/