From: "naruse (Yui NARUSE)" <naruse@...>
Date: 2012-12-12T17:32:50+09:00
Subject: [ruby-core:50813] [ruby-trunk - Feature #7549] A Ruby Design Process


Issue #7549 has been updated by naruse (Yui NARUSE).


> It does not need huge changes.

No, it needs  change.
Continuous changes is Ruby.

> Wherever this proposed process seems heavy, it has been designed to produce good decisions and limit Ruby changes.

I absolutely object this.
Don't prevent changing Ruby.

> proposed process

I think what such solid process generate is not Ruby.

Additionally I can't understand why you can belive MRI will implement suggested features on the process,
and you don't imagine MRI implement new features as implementation specific.

= Theses

== thesis 1: Ruby is matz'

matz has absolute right over materials named Ruby.
Even if matz transfer some right of designing and implementing privilege to other people, matz can always override it.

What people can do is to persuade matz or fork Ruby.

== thesis 2: Ruby is changing

Ruby must aim for ideal Ruby.
Even if it breaks compatibility, Ruby should change itself with some transition period.

== thesis 3: Standard language of discussion

Standard language of discussion of designing Ruby is C and Ruby.
People can use English, Japanese and other natural languages for assistance.
----------------------------------------
Feature #7549: A Ruby Design Process
https://bugs.ruby-lang.org/issues/7549#change-34652

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/