Anyone can propose a change. It just takes a lot of effort because language changes often have a lot of ramified implications. Most of the ideas are crap and it's frustrating to the originator but adding a process won't solve that issue.
Most of the discussions are available trough http://bugs.ruby-lang.org/ or the ruby-core mailing-list and the language's behaviour is well defined thanks to the http://rubyspec.org/ project.
The only real issue that I know of is that some of the discussions are done in Japanese which secludes the biggest part of the developers. Instead of proposing a scatter-gun solution it would be great to have something specific in that regard.
I for one would like to see a focus put on cleaning up the standard library (gem-ifying much of it?) rather than a design committee.
If a bug is recognised as such, simply don't implement it in the same way. If it's not, it's either a bug not previously discovered or intended behaviour.
http://www.ruby-lang.org/en/news/2003/12/19/new-ruby-change-...
The experiment…failed.
http://www.ruby-forum.com/topic/148408
While it would be nice to see more discussion off-email, I think that's hard enough to be unlikely.
I hope the failure in 2003-2008 doesn't predetermine the outcome of such an effort in 2012, assuming such an effort does takes place.
Seriously, problems around things like refinements aside, it seems to me that Ruby is progressing faster and more regularly than it has for years. Yes, it sometimes takes major alarmist posts by non-MRI implementers to get the attention of enough people to get a course adjusted (e.g., refinements), but I think that we're seeing much better collaboration and development on Ruby and more compatible Rubies than would be possible with the RCR mechanisms that were previously involved.
Imperfect, but by keeping to the tools that the main developers already use (email)…it is less problematic. I also think that it has helped that there have been implementor summits at several of the major conferences. Further, I think that it's helped that Matz himself is also working on an alternative implementation (mruby).
It would be interesting how these discussions pan our. something to keep an eye on
Huh?
I'm entirely open to the ideas proposed here, but I fail to see any ACTUAL benefits. The fact that a new process to define and manage the language prevents a rhetorical device from being used - that's a serious argument in favor of the change?
Am I missing something?
My article is still leaning heavily on Brian Ford's talk for the reasons why the current (lack of) process is an issue that needs consideration. I certainly could've done a better job of summarizing that before throwing in my 2 cents.
The lesson I learn from this is that with programming languages governance is part of the thing, radical changes affect everything. The language is not hived off from its governance.
