이 기사는 안도형 덕분에 한국어로도 볼 수 있습니다!
Thom Parkin은 제 이전 기사의 논평에서 중요한 지적을 했습니다.
<블록 인용>훌륭한 조언입니다. 그러나 당신은 매우 중요한 [최종] 포인트를 놓쳤습니다. 이것은 오픈 소스이기 때문에 문서가 약간 가벼운 해당 기능/기능의 세부 사항을 파악했다면 문서를 업데이트하고 풀 요청을 제출해야 합니다. 그런 식으로 전체 커뮤니티가 혜택을 받고 참여에 대한 "코더 자격"을 얻을 수도 있습니다!
매우 중요하기 때문에 Thom이 언급한 것을 기쁘게 생각합니다. . 문서를 수정하는 것은 여러분이 사용하고 사랑하는 프로젝트에 다시 기여할 수 있는 가장 쉬운 방법입니다.
Rails, Rubinius, Elixir와 같은 프로젝트에 대한 저의 첫 기여는 모두 문서 수정이었습니다. 저는 좀 더 명확하게 하기 위해 약간의 조정을 가했으며, 깨진 서식을 수정한 경우에도 코드를 읽어야만 발견할 수 있는 몇 가지 사항을 설명했습니다. 이것들은 모두 대규모 오픈 소스 프로젝트를 돕는 빠르고 쉬운 방법이었습니다. 그들이 프로젝트에 대한 나의 유일한 기여일지라도 그들은 여전히 미래의 사용자와 Future Me를 도왔습니다. 이것이 바로 오픈 소스의 핵심입니다.
문서 수정이 시작하는 좋은 방법인 이유
문서 수정은 Rails와 같은 큰 프로젝트에 기여할 수 있는 가장 위협적인 방법입니다.
-
버그를 수정하기 위해 프로젝트를 설정할 필요가 없습니다. . 문서를 업데이트하는 중이므로 테스트나 앱을 실행할 필요가 없습니다. 때로는 프로젝트를 컴퓨터에 복제할 필요조차 없습니다. GitHub에서 바로 변경할 수 있습니다!
-
관리자가 풀 리퀘스트를 변경하도록 요청하는 경우 일반적으로 문구나 취향의 문제입니다. . 이러한 종류의 변경은 코드에 대한 비판보다 이해하기 쉬울 수 있습니다. 테스트나 코드를 업데이트할 필요 없이 단어만 업데이트하면 되므로 이러한 변경 작업이 더 쉽습니다.
-
문서가 어려움 프로젝트 관리자를 위한 업데이트이므로 감사합니다. . 종종 작성자는 혼란스러운 부분이 어디에 있는지 이해하기 위해 코드에 너무 가깝습니다. 그들은 문서에 도움이 필요한 곳을 알려줄 다른 새로운 개발자가 필요합니다. 프로젝트를 초보자처럼 이해하려면 연습이 필요하며 모든 사람이 그러한 기술을 습득한 것은 아닙니다.
-
마침내, 영향이 적은 변경으로 유지 관리자와 관계를 구축하기 시작했습니다. . 전체 기능에 기여하는 것처럼 프로젝트의 방향을 변경하지 않습니다. 따라서 유지 관리자가 변경 사항을 더 쉽게 검토하고 일반적으로 더 빨리 응답합니다. 병합 요청이 "좋은 생각입니까?" 단계.
그 관계를 계속 구축하면서 신뢰할 수 있는 기여자로 보이기 시작할 것입니다. 귀하의 풀 리퀘스트가 더 빨리 검토될 것이며 더 복잡한 기능 요청 및 버그 수정에 대해 두 사람 모두 더 쉽게 이야기할 수 있을 것입니다.
시작하기 쉽고 수행하기 쉽고 더 빨리 병합되는 경향이 있습니다. 그렇다면 첫 번째 기여가 문서 수정이 되지 않는 이유는 무엇입니까?
업데이트된 문서를 다시 제공하는 방법
문서 업데이트에 기여하는 중요한 방법은 버그를 수정하는 것과 같습니다. 둘 다 잘못되었다고 느끼는 것에 민감합니다 . 주의를 기울여야 합니다.
예상치 못한 동작이 발생하면 문서를 업데이트해야 할 때일 수 있습니다. 문제를 해결하기 위해 코드를 자세히 살펴봐야 하는 경우 다른 사람들에게 이에 대해 이야기하고 싶을 수도 있습니다. 읽은 문서의 잘못된 형식과 오타에도 민감해야 합니다. 당신이 고칠 생각이 없다면 누가 고칠 것인가?
변경할 위치와 표현 방법에 대한 좋은 아이디어가 있으면 변경하고 GitHub를 통해 풀 리퀘스트를 보내세요.
여전히 문서를 업데이트하는 가장 좋은 방법을 결정하려고 한다면 GitHub에서 문제를 여십시오. 다음과 같을 수 있습니다.
“이봐, 이게 나한테 혼란스러웠어. 다음과 같이 업데이트할 생각이었습니다. ... 어떻게 생각하세요? 내가 더 언급해야 할 것이 있습니까?” 모두가 함께 만족할 수 있는 문구를 만들 수 있습니다.
마지막으로, 응답을 받지 못하더라도 낙심하지 마십시오. 큰 프로젝트는 진행 중인 작업이 많기 때문에 기여도가 깨지기 쉽습니다. 1주일 정도 후에도 여전히 연락이 없으면 관리자에게 다시 문의하세요. .
문서는 라이브러리 작업을 할 때 가장 먼저 접하는 경우가 많으므로 상세하고 명확하게 작성하는 것이 중요합니다.
따라서 사용하는 코드에 대해 혼란스럽거나 소스를 자세히 살펴봐야 하는 경우 다음 사람이 쉽게 사용할 수 있도록 하십시오. 빠른 업데이트를 작성하고 다시 제공하십시오. 오픈 소스 기여자가 되는 가장 쉬운 방법입니다.
이 기사는 원래 내 목록에 있는 사람들에게 보내졌습니다. 더 많은 것을 읽으려면 여기에서 가입하세요!