Hi,

In message "Re: [ruby-core:25188] Re: Patch writer's guide to submit"
    on Sun, 30 Aug 2009 07:26:21 +0900, Marc-Andre Lafortune <ruby-core-mailing-list / marc-andre.ca> writes:

|Reducing the submitters' frustration by reducing the delay for
|feedback is a fine goal. Maybe it would be best to improve the steps 2
|and 4 of http://www.ruby-lang.org/en/community/ruby-core/#patching-ruby
|?
|
|"2. Add your improvements to the code. Add tests in test/*/test_*.rb"
|"4. Send your patch with a detailed explanation of what issues it
|solves, ideally with code examples. As much as possible, keep changes
|separate by making a patch for each bug fix/new feature"

Agreed.

|My matrix patch (http://redmine.ruby-lang.org/issues/show/1532 )
|probably qualifies as a big patch (fixing half a dozen bugs and
|changing the behavior for many edge cases). I address the library as a
|whole because I feel that the issues I raise are all interrelated and
|that the library as a whole needs some love, but I would welcome some
|guidance as to how to break it in parts if that makes it easier.

Performance improvement (without changing behavior) is far easier to
be merged.  But enhancement, especially ones with behavioral changes
would be much harder, since "should" is often subjective.  In those
cases, you have to persuade us that your "should" is generic enough.
Remember that we are so lazy.  Perhaps I should write "patch writer's
guide to persuade code developers (or matz)" as different document.

							matz.