A Ruby Design Process
Ruby is a complex, mature programming language supported on numerous operating
systems (e.g. Unix, Linux, Windows, etc.) and on diverse platforms (e.g. JVM,
CLR, Smalltalk, etc.).
The Ruby programming language boasts at least six significant, full-featured
implementations, including MRI,
IronRuby, MacRuby, and
MagLev. There are also several special-purpose
derivatives of Ruby, include mruby,
Ruby has no formal design process, despite Ruby being an industrial strength
programming language, having hundreds of millions of dollars invested in
businesses built around the language. There is no process to maintain unity of
the Ruby language. There is no definitive resource defining Ruby. Developers
can only support multiple Ruby implementations with trial and error.
At RubyConf 2012, Brian Ford presented a
advocating a Ruby design process. The proposed process has been detailed in a
The Ruby design process is summarized below. Please see the blog post for
elaboration and clarification.
- A Ruby Design Council made up of representatives from any significant
Ruby implementation, where significant means able to run a base level of
RubySpec (which is to be determined).
- A proposal for a Ruby change can be submitted by any member of the Ruby
Design Council. If a member of the larger Ruby community wishes to submit a
proposal, they must work with a member of the Council.
- The proposal must meet the following criteria:
- An explanation, written in English, of the change, what use cases or
problems motivates the change, how existing libraries, frameworks, or
applications may be affected.
- Complete documentation, written in English, describing all relevant
aspects of the change, including documentation for any specific methods
whose behavior changes or behavior of new methods that are added.
- RubySpecs that completely describe the behavior of the change.
- When the Council is presented with a proposal that meets the above
criteria, any member can decide that the proposal fails to make a case that
justifies the effort to implement the feature. Such veto must explain in
depth why the proposed change is unsuitable for Ruby. The member submitting
the proposal can address the deficiencies and resubmit.
- If a proposal is accepted for consideration, all Council members must
implement the feature so that it passes the RubySpecs provided.
- Once all Council members have implemented the feature, the feature can be
discussed in concrete terms. Any implementation, platform, or performance
concerns can be addressed. Negative or positive impact on existing
libraries, frameworks or applications can be clearly and precisely
- Finally, a vote on the proposed change is taken. Each implementation gets
one vote. Only changes that receive approval from all Council members
become the definition of Ruby.
If you support the design process for Ruby outlined above, please let your
voice be heard by signing below.