새로운 기여자인데 어떻게 해야 할지 모르겠어요? 돕고 싶지만 어떻게 시작해야 할지 모르겠다고요? 여기가 당신을 위한 섹션입니다.
일어나서 달리십시오!
장고에 처음 기고하는 경우 :doc:’/intro/contribution’ 튜토리얼에서 도구와 워크플로우에 대해 설명합니다.
이 페이지에는 장고에 기여할 수 있는 방법과 장고에 접근하는 방법에 대한 보다 일반적인 조언이 포함되어 있습니다.
코드 기여에 대한 세부 정보를 보려면 :doc:’/internals/committing/writing-code/index’ 문서를 참조하십시오.
장고의 개발 과정을 알아보려면 다음 단계부터 시작하십시오.
`unreviewed ticket`_에서 버그가 보고되면, 해당 버그를 재현해 보세요. 재현이 가능하고 유효해 보인다면, 버그를 확인했다는 내용을 남기고 티켓을 할당받습니다. 티켓이 올바른 구성 요소 영역에 등록되어 있는지 확인하세요. 버그 자체를 수정하지 않더라도, 해당 동작을 검증하는 테스트를 추가하는 패치를 작성하는 것도 고려해 볼 수 있습니다. 자세한 내용은 :ref:`how-can-i-help-with-triaging`을 참고하세요.
이는 코드베이스와 개발 프로세스에 익숙해지는 데 도움이 됩니다. 패치에 문서나 테스트가 필요한 경우 해당 플래그를 표시하세요. 패치가 변경한 내용을 검토하고, 아직 지원되는 이전 Python 버전과 호환되지 않는 구문이 있는지 확인하세요. :doc:`Run the tests </internals/contributing/writing-code/unit-tests>`를 실행해 테스트가 통과하는지 확인합니다. 가능하다면 SQLite가 아닌 다른 데이터베이스에서도 패치를 실행해 보세요. 코멘트와 피드백을 남겨주세요!
패치 제출 이후 검토되기까지의 기간 동안 코드베이스가 변경되는 경우가 많습니다. 패치가 여전히 충돌 없이 적용되는지, 예상대로 동작하는지 확인해 주세요. 패치를 최신 상태로 유지하는 것은 유익하고 중요한 작업입니다! 자세한 내용은 :ref:`patch-review-checklist`을 참고하세요.
Django의 문서는 훌륭하지만 언제나 개선의 여지가 있습니다. 오타를 발견하셨나요? 더 명확히 설명할 필요가 있다고 생각하시나요? 문서 패치를 제안해 보세요! 문서 작성하기 가이드도 참고하세요.
참고
‘reports page’_에는 위에서 제안한 바와 같이 티켓을 분류하고 패치를 검토하는 데 유용한 몇 가지 트랙 쿼리에 대한 링크가 포함되어 있습니다.
작성한 코드는 작성자 본인 또는 소속된 회사에 귀속됩니다. 코드 기여가 한두 줄을 넘는 경우 `CLA`_에 서명할 수 있습니다. 자세한 내용은 `Contributor License Agreement FAQ`_를 참고하세요.
큰 프로젝트에 새로 온 사람은 좌절감을 느끼기 쉽습니다. 여기 장고에 대한 여러분의 작업을 더 유용하고 보람 있게 만들기 위한 몇 가지 조언이 있습니다.
관심이 있거나, 익숙하거나, 배우고 싶은 분야를 선택하세요. 작업하고자 하는 분야의 전문가일 필요는 없습니다. 코드에 꾸준히 기여하다 보면 자연스럽게 전문가가 됩니다.
트랙은 절대적인 것이 아닙니다. 문맥은 단어만큼 중요합니다. 트랙을 읽을 때, 여러분은 누가 어떤 말을 하는지, 언제 어떤 말을 했는지 고려해야 합니다. 2년 전 아이디어에 대한 지원이 반드시 그 아이디어가 여전히 지지를 받는다는 것을 의미하지는 않습니다. 여러분은 또한 누가 말을 하지 않았는지도 관심을 가질 필요가 있습니다. 예를 들어, 경험 많은 기여자가 최근에 토론에 참여하지 않았다면, 티켓은 장고에 들어가는 데 필요한 지원을 받지 못할 수도 있습니다.
큰 문제보다 작은 문제에 대한 피드백을 받는 것이 더 쉽습니다. ‘쉬운 선택’을 참조하십시오.
즉, 문제를 수정하기 전에 다른 사람이 버그가 실제인지 확인하도록 하고, 버그를 구현하기 전에 제안된 기능에 대한 합의가 있는지 확인하는 것입니다.
때때로 자신의 의견을 세상에 내놓고 “이 표는 정확하다”거나 “이 패치는 작업이 필요하다”고 말하는 것이 두려울 수 있지만, 이것은 프로젝트가 앞으로 나아갈 수 있는 유일한 방법입니다. 넓은 장고 공동체의 기여는 궁극적으로 한 사람의 기여보다 훨씬 더 큰 영향을 미칩니다. 여러분이 없이는 못 합니다!
티켓이 준비되었는지 확실하지 않다면, 준비된 것으로 표시하지 마세요. 대신 다른 사람들이 상황을 이해할 수 있도록 코멘트를 남기세요. 대체로 확신이 있지만 완전히 확실하지 않은 경우에는 Django Discord server`_의 ``#contributing-getting-started` 채널에서 다른 사람이 확인해 줄 수 있는지 물어볼 수도 있습니다.
티켓 한 장 또는 두 장에 집중하여 처음부터 끝까지 보고 반복합니다. 많은 표를 가지고 어떤 사람들은 도중에 넘어지게 하는 산탄총 같은 접근법은 결국 득보다 실이 더 많습니다.
“PEP 8, 그리고 문서와 테스트를 반드시 포함해야 한다”고 할 때는 이를 반드시 지켜야 한다는 뜻입니다. 패치에 문서와 테스트가 없다면, 그에 대한 충분한 이유가 있어야 합니다. “이 기능에 대한 기존 테스트를 찾을 수 없었습니다”와 같은 주장은 설득력이 없습니다. 그런 경우라면 해당 기능에 대한 첫 번째 테스트를 작성해야 하는 중요한 역할을 맡게 되는 것이지, 테스트 작성을 면제받는다는 뜻은 아닙니다.
티켓이나 패치가 빠르게 검토되는 것이 항상 쉬운 것은 아닙니다. 이건 개인적인 일이 아니에요. 통과하기 위해 많은 티켓과 풀 요청이 있습니다.
패치를 최신 상태로 유지하는 것이 중요합니다. 모든 검토 코멘트를 처리한 후 Trac에서 티켓을 검토하여 테스트 필요, 문서 필요 및 패치 개선 필요 플래그가 선택 취소되었는지 확인하십시오.
Django의 릴리스 주기가 8개월이라는 점을 고려하면 패치가 검토될 시간은 충분합니다.
마지막으로, 적절한 시기에 상기시키는 것이 도움이 될 수 있습니다. 아이디어에 대한 자세한 내용은:ref:’코드 기여 FAQ’를 참조하십시오.
8월 05, 2026