Improve translation on the article 5, section 1~2

Author: reverince

_articles/ko/best-practices.md

@@ -1,96 +1,98 @@
 ---
 lang: ko
-title: 메인테이너를 위한 모범 사례
-description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈소스 메인테이너로서 여러분의 삶을 편하게 만들어줍니다.
+title: 관리자의 모범
+description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈소스 관리자로서 여러분의 삶을 더 편하게 만들어 줍니다.
 class: best-practices
 toc:
   what-does-it-mean-to-be-a-maintainer: "메인테이너가 된다는 것은 무엇을 의미하나요?"
-  documenting-your-processes: "진행과정을 문서화하기"
-  learning-to-say-no: "아니오라고 말하는 것을 배우기"
+  documenting-your-processes: "프로세스 문서화하기"
+  learning-to-say-no: "거절하는 법 배우기"
   leverage-your-community: "커뮤니티 활용하기"
   bring-in-the-robots: "로봇 가져오기"
-  its-okay-to-hit-pause: "멈추는것도 좋습니다"
+  its-okay-to-hit-pause: "잠시 멈춰도 괜찮습니다"
 order: 5
 image: /assets/images/cards/best-practices.png
 related:
   - metrics
   - leadership
 ---
 
-## What does it mean to be a maintainer?
+## 관리자라는 직책이란
 
-많은 사람들이 사용하는 오픈소스 프로젝트를 유지한다면, 적은 양으로 코딩하고 더 많은 이슈에 대응할 수 있습니다.
+여러분이 많은 사람들이 사용하는 오픈소스 프로젝트를 관리하고 있다면, 점점 코딩은 덜 하고 이슈에 더 많이 반응하고 있다는 것을 알아차렸을 것입니다.
 
-프로젝트 초기 단계에서 새로운 아이디어를 실험하고 원하는 것을 기반으로 의사 결정을 내리고 있습니다. 프로젝트의 인기가 높아짐에 따라 사용자와 기여자들과 더 잘 일할 수 있습니다.
+프로젝트의 초기 단계에서, 여러분은 새로운 아이디어를 실험하고 여러분이 원하는 것을 바탕으로 결정을 내리고 있습니다. 프로젝트가 인기를 끌면서 여러분은 사용자 및 기여자들과 더 많은 일을 하게 될 것입니다.
 
-프로젝트를 유지하려면 코드 이상의 것을 요구합니다. 이러한 작업은 예상치 못한 경우가 많지만 성장하는 프로젝트와 마찬가지로 중요합니다. 우리는 진행 문서화에서 시작해서 커뮤니티 활용에 이르기까지 당신의 삶을 편하게 해주는 몇 가지 방법을 모아봤습니다.
+프로젝트 유지에는 코드 이상의 것이 필요합니다. 종종 예상치 못한 과제가 주어지기도 하지만 성장하는 프로젝트에게 이는 중요한 일입니다. 프로세스를 문서화하는 것에서부터 커뮤니티를 활용하는 것까지 여러분의 삶을 더 쉽게 만들 수 있는 몇 가지 방법을 모아 보았습니다.
 
-## Documenting your processes
+## 프로세스 문서화하기
 
-글을 작성하는 것은 메인테이너가 할 수있는 가장 중요한 일 중 하나입니다.
+기록해두는 것은 여러분이 관리자로서 할 수 있는 가장 중요한 일 중 하나입니다.
 
-문서는 자신의 생각을 분명히 할 뿐만 아니라, 다른 사람들이 물어보기도 전에 필요하거나 기대하는 것을 이해하도록 도와줍니다.
+문서화는 여러분의 생각을 분명히 할 뿐만 아니라 여러분이 필요로 하거나 기대하는 것을 사람들이 직접 물어보지 않고도 알 수 있게 합니다.
 
-글을 쓰게되면 무언가 범위에 맞지 않을 때 아무 말도 달지 않게됩니다. 또한 사람들이 쉽게 참여하게 도움을 줍니다. 다만 누가 프로젝트를 읽고 사용하는지 알 수는 없습니다.
+문서화를 해 두면 여러분의 의도에 맞지 않는 의견을 기각하기 더 쉬워집니다. 또한 사람들이 프로젝트에 참여하기 더 쉽게 만듭니다. 어떤 사람들이 여러분의 프로젝트를 보거나 사용하고 있는지 모르니까요.
 
-전체 단락을 사용하지 않더라도, 글 머리 기호라도 적어둔다면 아에 작성하지 않는 것보다는 좋습니다.
+모든 항목에 대해 작성하지 않아도 괜찮습니다. 주요 항목에 대해 적어두는 것이 아무 것도 적어놓지 않는 것보다는 낫습니다.
 
-### 프로젝트의 비전을 써내려가기
+여려분의 문서를 항상 최신으로 유지할 수 있도록 노력하세요. 항상 업데이트하기 어렵다면 오래된 문서를 지우거나 'outdated'로 표시해서 기여자들의 업데이트를 환영한다고 알리세요.
 
-먼저 프로젝트의 목표를 써내려갑니다. README에 추가하거나, VISION이라 불리는 별도의 파일을 작성하십시오. 프로젝트 로드맵과 같이 도움이 될 수 있는 다른 인위적인 결과물이 있는 경우, 이를 공개 할 수도 있습니다.
+### 프로젝트의 비전을 서술하세요
 
-명확하고, 문서화된 비전을 가지고 있으면 집중력을 유지하고 다른 기여자로부터 "scope creep"를 피할 수 있습니다.
+프로젝트의 목표를 이야기하는 것부터 시작하세요. 이를 README 파일 또는 새로운 VISION 파일에 추가하세요. 프로젝트 로드맵 등 도움이 될만한 자료가 더 있다면 그것도 게시하세요.
 
-예를 들어, @lord는 프로젝트 비전을 가짐으로써 시간을 보낼 요청을 파악하는 데 도움이 된다는 것을 발견했습니다. 새로운 메인테이너인 그는 [Slate](https://github.com/lord/slate)에 대한 첫번째 기능 요청을 받았을 때 프로젝트의 범위를 고수하지 않은 것을 후회했습니다.
+명료하고 문서화된 비전은 여러분을 집중할 수 있게 하고, 사람들의 기여로부터 생길 수 있는 'scope creep'을 피할 수 있도록 해줍니다.
+
+예를 들어 @lord는 프로젝트 비전을 가지면 어떤 요구에 시간을 투자해야 하는지 파악하는 데 도움이 된다는 사실을 깨달았습니다. 새로운 관리자로서의 그는 [Slate](https://github.com/lord/slate)의 첫 기능 요청을 받았을 때 프로젝트의 본 목적에 집중하지 않았던 것을 아쉽게 생각했습니다.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
   I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
   <p markdown="1" class="pquote-credit">
-— @lord, ["새로운 오픈소스 메인테이너를 위한 팁"](https://lord.io/blog/2014/oss-tips/)
+— @lord, ["Tips for new open source maintainers”](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
-### 생각을 소통하기
+### 기대하는 바를 전달하세요
 
-규칙은 신경을 쓸 수록 더 쓰일 수 있습니다. 때로는 다른 사람들의 행동을 감시하거나 모든 재미를 없애는 것처럼 느껴질 수도 있습니다.
+규칙을 나열하는 것은 머리 아픈 일입니다. 가끔 여러분이 사람들의 행동에 간섭하거나 재미를 없애는 것이 아닌가 하는 생각이 들 수도 있습니다.
 
-그러나 공정하게 작성되고 시행되면, 좋은 규칙은 메인테이너에게 힘을 줍니다. 그것들은 하고 싶지 않은 일을 하도록 끌리지 못하게 합니다.
+그러나 공정하게 제정되고 시행되는 좋은 규칙은 관리자에게 제어력을 부여합니다. 하고 싶지 않은 일에 억지로 끌려들어가지 않게 해줍니다.
 
-프로젝트를 직접 경험하는 대부분의 사람들은 메인테이너가 겪는 상황에 대해 알지 못합니다. 그들은 그것에 대해 일하기 위해 돈을 받는다고 가정할 지도 모릅니다, 특히 그들이 정기적으로 사용하고 의존하는 것들이 대부분입니다. 하지만 메인테이너는 어쩌다 한번에 프로젝트에다가 많은 시간을 할애하지만, 이제는 새로운 직업이나 가족 구성원으로인해 바빠졌습니다.
+여러분의 프로젝트를 찾아오는 대부분의 사람들은 여러분이나 여러분의 환경에 대해 아무것도 알지 못합니다. 프로젝트에 의지하며 꾸준히 사용하는 사람들은 여러분이 그 프로젝트에서 작업하면서 보수를 받는다고 추측할지도 모릅니다. 언젠가는 프로젝트에 많은 시간을 쏟아부을 수 있었어도 이제는 새 직장이나 가족 구성원으로 정신없을 수도 있습니다.
 
-이 모든 것은 완벽하게 괜찮습니다! 다른 사람들이 그것에 대해 알고 있는지 확인하시기 바랍니다.
+전부 괜찮습니다! 대신 사람들에게 그렇다는 사실을 알리세요.
 
-당신의 프로젝트를 아르바이트로 유지하거나 순수하게 자원 봉사로 진행하는 경우, 당신이 가진 시간에 대해 솔직하게 말하십시오. 이것은 프로젝트가 요구하는 시간, 또는 다른 사람들이 당신의 개발에 소비하기를 원하는 시간과 같지 않습니다.
+프로젝트 관리를 아르바이트식 혹은 자발적으로 하고 있다면 여러분이 가진 시간에 대해 솔직해지세요. 프로젝트에 투자해야 한다고 여러분이 생각하는 시간과, 사람들이 여러분이 프로젝트에 투자하기를 원하는 시간과는 다릅니다.
 
-다음과 같은 몇 가지 규칙을 적어 두는 것이 좋습니다:
+아래와 같은 규칙은 정해 두는 편이 좋습니다.
 
-* 기여를 검토하고 수락하는 방법 (_검사가 필요한가요? 이슈 템플릿?_)
-* 당신이 수락할 기여 유형 (_코드의 특정 부분에 대해서만 도움을 원하십니까?_)
-* 후속 조치가 필요한 순간 (_ex. "7일 이내에 관리자로부터 응답을 받을 수 있습니다. 그때까지 아무 것도 듣지 못했다면 쓰레드에 핑을 보내세요."_)
-* 프로젝트에 할애하는 시간 (_ex. "이 프로젝트에 일주일 중 약 5시간만 할애하고 있습니다."_)
+* 기여를 검토하고 받아들이는 방식 (_테스트를 수행해야 하나요? 정해진 이슈 템플릿이 있나요?_)
+* 여러분이 받아들이고자 하는 기여 유형 (_코드의 일부분에만 기여를 받고 싶은가요?_)
+* 피드백까지 예상되는 시간 (_ex. "일주일 안에는 관리자의 답변을 받으실 수 있을 것입니다. 그때까지 소식이 없다면 주저 말고 스레드에서 관리자를 호출해주세요" 등._)
+* 여러분이 프로젝트에 투자하는 시간 (_ex. "저희는 이 프로젝트에 일주일에 약 5시간만을 할애하고 있습니다" 등._)
 
-[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), 및 [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md)는 메인테이너와 기여자를 위한 기본 원칙이 있는 프로젝트의 몇 가지 예시입니다.
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md)는 관리자와 기여자를 위한 행동 원칙을 가진 프로젝트의 예시입니다.
 
-### 열린 소통을 유지하기
+### 열린 소통을 유지하세요
 
-상호 작용을 문서화하는 걸 잊지 마십시오. 가능한 모든 곳에서 프로젝트 공개에 대한 의사 소통을 유지하십시오. 누군가가 개인적으로 연락하여 기능 요청 또는 지원 필요성에 대해 토론하려고하면, 정중하게 메일링 리스트 또는 이슈 트래커와 같은 공개 의사 소통 채널로 안내합니다.
+다양한 토의나 질답을 문서화하는 것을 잊지 마세요. 가능하면 어디에서든 여러분의 프로젝트에 대한 이야기는 공개적으로 하는 것이 좋습니다. 누군가 기능이나 지원 요청을 하기 위해 사적으로 연락한다면, 정중하게 메일링 리스트 혹은 이슈 트래커 등의 공개된 채널로 안내하세요.
 
-다른 메인테이너와 만나거나, 비공개로 중요한 결정을 내릴 경우, 또는 메모를 게시하는 경우에도 마찬가지로, 공개적으로 문서에 기록하십시오.
+다른 관리자와 만나거나, 공개하기 어려운 중요한 결정을 내린다면 여러분의 메모 정도라고 해도 내용은 공개적으로 게시하세요.
 
-그러면, 커뮤니티에 가입한 사람은 수년간 그 곳에 있었던 사람과 동일한 정보에 접근 할 수 있습니다.
+그러면 여러분의 프로젝트에 막 찾아온 사람도 몇 년간 있었던 사람과 같은 양의 정보를 획득할 수 있습니다.
 
-## Learning to say no
+## 거절하는 법 배우기
 
-당신이 글을 썼습니다. 이상적으로는 모든 사람이 당신의 문서를 읽을 것이지만, 실제로 이 지식이 존재한다는 것을 모르는 다른 사람들에게도 상기시켜야 할 것입니다.
+필요한 것들을 문서화했나요? 모두가 문서를 읽는다면 이상적이겠지만 현실은 그렇지 않습니다. 사람들에게 그런 문서가 있다는 사실을 알려주어야 합니다.
 
-그러나 모든 것을 적어둔다면, 규칙을 집행해야 할 상황일때 평범한 상황으로 복귀하는 것에 도움이 됩니다.
+그러나 모든 것을 기록하면 규칙을 적용해야 할 때 객관적으로 상황을 해결할 수 있습니다.
 
-아니오라고 말하는 것은 재미없지만, _"기여가 이 프로젝트의 기준과 일치하지 않습니다."_ 는 _"전 당신의 기여가 싫어요"_ 보다 개인적인 느낌이 들었습니다.
+거절하는 것은 썩 유쾌한 일이 아닙니다. 하지만 _"당신의 기여는 프로젝트 기준에 맞지 않아요."_가 _"당신의 기여가 마음에 들지 않네요."_보다는 덜 감정적으로 느껴집니다.
 
-당신이 메인테이너로서 만날 수 있는 많은 상황에 적용됩니다: 범위에 맞지 않는 기능 요청, 토론을 이탈한 사람, 불필요한 다른 일을 하는 사람들.
+관리자로서, 본 목적에 맞지 않는 기능 요청, 토론과 관련 없는 발언, 불필요한 작업 등 거절이나 제지가 필요한 많은 상황을 맞닥뜨릴 것입니다.
 
-### 친근한 대화를 유지하기
+### 친절한 태도를 유지하세요
 
 가장 중요한 장소 중 하나인 No라고 말하면서 이슈와 pull request 대기열을 가져옵니다. 프로젝트 메인테이너로서, 여러분은 받아들이기를 원치않는 제안을 필연적으로 받게됩니다.
 
@@ -162,7 +164,7 @@ related:
 
 누군가 당신의 프로젝트에 열성적이지만 약간의 수정이 필요하다면 인내심을 가집시다. 그들의 공헌이 프로젝트의 기대에 부합하지 않는 이유를 각 상황에서 분명하게 설명합니다. 발을 젖게하기 위해 _"좋은 첫 버그,"_라고 표시된 이슈와 같이 더 쉽거나 덜 모호한 작업을 가리키도록 하십시오. 시간이 있다면, 첫번째 기여를 통해 멘토링을 고려하거나 멘토를 기꺼이 도울 수 있는 다른 사람을 커뮤니티에서 찾을 수 있습니다.
 
-## Leverage your community
+## 커뮤니티 활용하기
 
 당신은 모든 것을 스스로 할 필요가 없습니다. 프로젝트 공동체가 존재합니다! 적극적으로 참여한 커뮤니티가 없는 경우에도 많은 사용자가 있는 경우, 일하도록 하십시오.
 
@@ -248,7 +250,7 @@ related:
 
 어떤 도구를 사용해야하는지 잘 모르는 경우 다른 인기있는 프로젝트, 특히 같은 생태계에 있는 프로젝트를 살펴보십시오. 예를 들어, 다른 Node 모듈에 대한 기여 진행과정은 어떻게됩니까? 유사한 도구와 접근 방식을 사용하면 진행과정은 대상 기여자에게 더 익숙하게 됩니다.
 
-## It's okay to hit pause
+## 잠시 멈춰도 괜찮습니다
 
 오픈소스 작업은 한 때 기쁨을 가져다주었습니다만. 어쩌면 이제는 회피하거나 죄책감을 느낄 수 있습니다.