diff --git a/ko/community/ruby-core/writing-patches/index.md b/ko/community/ruby-core/writing-patches/index.md
new file mode 100644
index 0000000000..ecd3f5e786
--- /dev/null
+++ b/ko/community/ruby-core/writing-patches/index.md
@@ -0,0 +1,48 @@
+---
+layout: page
+title: "패치 작성자를 위한 지침"
+lang: ko
+---
+
+다음은 마츠 씨가 직접 언급한 좋은 패치를 만드는 방법입니다.
+{: .summary}
+
+이 지침은 Ruby-Core 메일링 리스트의 [마츠 씨의 글][ruby-core-post]에서
+가져왔습니다.
+
+* 패치당 하나의 수정사항 구현하기
+
+  이는 대부분의 보류 중인 패치들이 갖고 있는 가장 큰 문제입니다. 여러 개의
+  버그를 수정하는 (또 여러 기능을 추가하는) 패치를 한 번에 보내면, 우리는 이를
+  다시 나눠서 적용해야 합니다. 이는 바쁜 개발자에게는 상대적으로 힘든 작업이
+  되기에, 이런 유형의 패치는 자주 보류되곤 합니다. 큰 패치를 보내지 말아주세요.
+
+* 설명 제공하기
+
+  가끔 어떤 문제를 고치는지에 대한 충분한 설명이 없는 패치가 들어오곤 합니다. 좀
+  더 나은 설명(패치가 고치는 문제점, 전제조건, 플랫폼 등)과 함께라면 패치가 더
+  일찍 병합될 수 있을 것입니다.
+
+* 최신 리비전 기반으로 패치 작성하기
+
+  고치려는 문제가 이미 최신 리비전에서 수정되었을 수 있습니다. 코드가 완전히
+  달라졌을 수도 있습니다. 패치를 제출하기 전에 서브버전 저장소에서 최신
+  버전(최신 개발 버전은 `trunk` 브랜치, {{ site.svn.stable.version }} 버전은
+  `{{ site.svn.stable.branch }}` 브랜치)을 받아 보세요.
+
+* `diff -u` 사용하기
+
+  우리는 `diff -c`나 다른 스타일보다 `diff -u`의 unified diff 스타일의 패치를
+  선호합니다. 그게 리뷰하기 훨씬 쉽습니다. 수정한 파일을 보내지 마세요. 직접
+  diff를 만들고 싶지 않습니다.
+
+* 테스트 케이스 추가하기(선택 사항)
+
+  패치가 테스트 케이스(`test/*/test_*.rb`에 패치하는 게 좋습니다)를 제공하면
+  작성자의 의도와 패치를 이해하는 데 도움이 됩니다.
+
+추후에는 Git 스타일 push/pull 워크플로로 옮겨갈 수 있습니다. 하지만 그 전까진
+위의 지침을 따른다면 낙심할 일을 줄일 수 있을 겁니다.
+
+
+[ruby-core-post]: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/25139