RCR Submission Guidelines and Procedures

Before you submit an RCR...

One of the main goals of RCRchive is to make the RCR submission process more consistent and rigorous. Matz has asked that submissions follow a particular format, which he described in his presentation at RubyConf 2003.

Here is some important advice that you should follow if you are thinking of submitting an RCR:

• Do not submit an RCR if Ruby is new to you. The Ruby community welcomes everyone, but experience suggests that it pays to spend some time with the language, and in its community, before suggesting changes to the language.
• Make sure the RCR you are writing has not already been submitted. To do this thoroughly you must check the following:
  • pending
  • accepted
  • rejected
  and you should also do a search in the ruby-talk archives (comp.lang.ruby on Google), in case your idea has already come up and possibly been commented on negatively by Matz (or by others who had valid objections to it).
• Read the advice in Jim Weirich's "Writing an RCR" page.
• Consider discussing your RCR idea on IRC (#ruby-lang on freenode.net). This can help you troubleshoot your idea, and see whether anyone brings up any important problems with it up front.

Once you decide to submit an RCR...

Once you decide to submit an RCR, you should keep the following in mind:

• Matz has stated what he wants the RCRs to include, and he has also written a sample RCR. Some details of the process have changed, but you should definitely read what Matz says about it.
• Look at the local RCRchive descriptions of the components of an RCR.
• Make sure your RCR involves only one change. Do not combine multiple requests into one.
• Choose a meaningful title for your RCR; don't use a cutesy or joking title.
• If at all possible, include an implementation of your RCR, preferably in Ruby. This is not mandatory, but can be very helpful as people try to evaluate what you're proposing.

RCRchive copyright © David Alan Black, 2003-2005.

Powered by Ruby on Rails.