Writer’s Guide

Here follow some tips, straight from Matz, on how to get your es considered.

These guidelines were adopted from a post by Matz on the Ruby-Core mailing list:

  • Implement one modification per

    This is the biggest issue for most deferred es. When you submit a that fixes multiple bugs (and adds features) at once, we have to separate them before applying it. It is a rather hard task for us busy developers, so this kind of es tends to be deferred. No big es please.

  • Provide descriptions

    Sometimes a mere does not sufficiently describe the problem it fixes. A better description (the problem it fixes, preconditions, platform, etc.) would help a to be merged earlier.

  • Diff to the latest revision

    Your problem might have been fixed in the latest revision. Or the code might be totally different by now. Before submitting a , try to fetch the latest version (the trunk branch for the latest development version, ruby_2_6 for 2.6) from the Subversion repository, please.

  • Use diff -u

    We prefer diff -u style unified diff es to diff -c or any other style of es. They are far easier to review. Do not send modified files, we do not want to make a diff by ourselves.

  • Provide test cases (optional)

    A providing test cases (preferably a to test/*/test_*.rb) would help us understand the and your intention.

We might move to a Git style push/pull workflow in the future. But until then, following the above guidelines would help you to avoid frustration.