RCR Submission Guidelines and Procedures

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 (see link below).

• Before you submit an RCR, make sure it has not already been submitted. To do this, check the following:
  • pending
  • accepted
  • rejected
• You should study the descriptions of the components of an RCR and make sure that your submission is in conformity with them.
• Also, please look at from RubyConf 2003 (and click one or two slides to either side of that one). Some details of the process have changed but you should definitely read what Matz says about it.
• Only submit one change per RCR; don't combined 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.

Another good resource is .

Once you've submitted an RCR, you can perform the editing and maintenance actions described here.

Back to RCRchive Help Center.

Back to RCRchive.