以下是一些来自 Matz 的关于如何让你的补丁被考虑的建议。
这些指南改编自 Matz 在 Ruby-Core 邮件列表上的帖子
-
每个补丁实现一个修改
这是大多数被延迟的补丁的最大问题。当你提交一个补丁，同时修复多个错误（并添加功能）时，我们必须在应用它之前将它们分开。对于我们这些忙碌的开发人员来说，这是一个相当艰巨的任务，所以这种补丁往往会被延迟。请不要提交大的补丁。
-
提供描述
有时，仅仅一个补丁并不能充分描述它所修复的问题。更好的描述（它修复的问题、前提条件、平台等）有助于补丁更早地合并。
-
对比最新版本
你的问题可能已经在最新版本中修复了。或者现在的代码可能完全不同了。在提交补丁之前，请尝试从 Subversion 仓库中获取最新版本（最新的开发版本使用
trunk分支，2.6 版本使用ruby_2_6分支）。 -
使用
diff -u我们更喜欢
diff -u风格的统一差异补丁，而不是diff -c或任何其他风格的补丁。它们更容易审查。请不要发送修改过的文件，我们不想自己进行差异比较。 -
提供测试用例（可选）
提供测试用例的补丁（最好是
test/*/test_*.rb的补丁）将帮助我们理解补丁和你的意图。
我们将来可能会转向 Git 风格的推送/拉取工作流程。但在那之前，遵循上述指南将有助于你避免挫败感。