From: "naruse (Yui NARUSE)" Date: 2012-12-21T12:49:36+09:00 Subject: [ruby-core:51020] [ruby-trunk - Feature #7549] A Ruby Design Process Issue #7549 has been updated by naruse (Yui NARUSE). nathany (Nathan Youngman) wrote: > @brixen I feel that your proposed process is requesting too many changes all at once. We need to take small steps. > > I humbly suggest that we rely on prior works. Let's borrow from our neighbours, by adapting the processes other language communities use successfully. Then trim them down to what we can reasonably implement. > > To that end, I suggest that we all read through the "Python Enhancement Proposal: Purpose and Guidelines". It could provide a good starting point, with written proposals that may be accepted or rejected, but without chagoalnging the role of Matz as BDFL. http://www.python.org/dev/peps/pep-0001/ We had already tried to adopt some process like PEP, but it failed. It is because of what headius said in [ruby-core:50838] "6. Discussion begins". You may know, we CRuby people often discuss feature with patch. With patch we can use a proposed feature by hand and design better API. PEP is not suitable for such situation, so we finally adopt Redmine based process. https://bugs.ruby-lang.org/projects/ruby/wiki/HowToRequestFeatures This process is more open and everyone can propose feature. > > A summary and a few more thoughts are posted to my blog: > > http://nathany.com/ruby-design > Wouldn't it be nice to see Matz's proposal for refinements, and its subsequent acceptance ��� or rejection. :-P Did you read https://bugs.ruby-lang.org/issues/4085 ? > We need a comprehensive language reference. Is the Ruby Core Reference the closest thing we have to the Python Language Reference? :-( The Ruby Core Reference is generated from MRI's rdoc. > But we gain the benefits of document driven design. Newly added feature for MRI shall have rdoc even if some present features doesn't have. zzak is adding documents for such APIs, and drbrain and other collaborators did Ruby 1.9.3 Documentation Challenge. http://blog.segment7.net/2011/05/09/ruby-1-9-3-documentation-challenge They are great work and you can start your work from the point. ---------------------------------------- Feature #7549: A Ruby Design Process https://bugs.ruby-lang.org/issues/7549#change-34922 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/