다음은 마츠 씨가 직접 언급한 좋은 패치를 만드는 방법입니다.
{: .summary}

이 지침은 Ruby-Core 메일링 리스트의 [마츠 씨의 글][ruby-core-post]에서
가져왔습니다.

* 패치당 하나의 수정사항 구현하기

  이는 대부분의 보류 중인 패치들이 갖고 있는 가장 큰 문제입니다. 여러 개의
  버그를 수정하는 (또 여러 기능을 추가하는) 패치를 한 번에 보내면, 우리는 이를
  다시 나눠서 적용해야 합니다. 이는 바쁜 개발자에게는 상대적으로 힘든 작업이
  되기에, 이런 유형의 패치는 자주 보류되곤 합니다. 큰 패치를 보내지 말아주세요.

* 설명 제공하기

  가끔 어떤 문제를 고치는지에 대한 충분한 설명이 없는 패치가 들어오곤 합니다. 좀
  더 나은 설명(패치가 고치는 문제점, 전제조건, 플랫폼 등)과 함께라면 패치가 더
  일찍 병합될 수 있을 것입니다.

* 최신 리비전 기반으로 패치 작성하기

  고치려는 문제가 이미 최신 리비전에서 수정되었을 수 있습니다. 코드가 완전히
  달라졌을 수도 있습니다. 패치를 제출하기 전에 서브버전 저장소에서 최신
  버전(최신 개발 버전은 `trunk` 브랜치, 2.6 버전은
  `ruby_2_6` 브랜치)을 받아 보세요.

* `diff -u` 사용하기

  우리는 `diff -c`나 다른 스타일보다 `diff -u`의 unified diff 스타일의 패치를
  선호합니다. 그게 리뷰하기 훨씬 쉽습니다. 수정한 파일을 보내지 마세요. 직접
  diff를 만들고 싶지 않습니다.

* 테스트 케이스 추가하기(선택 사항)

  패치가 테스트 케이스(`test/*/test_*.rb`에 패치하는 게 좋습니다)를 제공하면
  작성자의 의도와 패치를 이해하는 데 도움이 됩니다.

추후에는 Git 스타일 push/pull 워크플로로 옮겨갈 수 있습니다. 하지만 그 전까진
위의 지침을 따른다면 낙심할 일을 줄일 수 있을 겁니다.


[ruby-core-post]: https://blade.ruby-lang.org/ruby-core/25139