새로운 기여자인데 어떻게 해야 할지 모르겠어요? 돕고 싶지만 어떻게 시작해야 할지 모르겠다고요? 여기가 당신을 위한 섹션입니다.
\n\n이 페이지에는 장고에 기여할 수 있는 방법과 장고에 접근하는 방법에 대한 보다 일반적인 조언이 포함되어 있습니다.
\n코드 기여에 대한 세부 정보를 보려면 :doc:’/internals/committing/writing-code/index’ 문서를 참조하십시오.
\n장고의 개발 과정을 알아보려면 다음 단계부터 시작하십시오.
\n검토되지 않은 티켓에서 버그가 보고되면 다시 재생성해 보십시오. 만약 당신이 그것을 재현할 수 있고 그것이 유효해 보인다면, 버그를 확인했다는 것을 메모하고 티켓을 받아들입니다. 티켓이 올바른 구성 요소 영역 아래에 정리되어 있는지 확인하십시오. 버그 자체를 수정하지 않더라도 버그의 동작에 대한 테스트를 추가하는 패치를 작성하는 것을 고려해 보십시오. 자세한 내용은 다음 사이트를 참조하십시오.참조:어떻게 하면 트라이얼을 할 수 있을지
\nThis will help you build familiarity with the codebase and processes. Mark the\nappropriate flags if a patch needs docs or tests. Look through the changes a\npatch makes, and keep an eye out for syntax that is incompatible with older but\nstill supported versions of Python. Run the tests and make sure they pass.\nWhere possible and relevant, try them out on a database other than SQLite.\nLeave comments and feedback!
\n종종 코드베이스는 제출되는 패치와 검토되는 시간 사이에서 변경됩니다. 여전히 깨끗하게 적용되고 예상대로 작동하는지 확인하십시오. 패치를 업데이트하는 것은 유용하고 중요합니다! :doc:’writing-code/submitting-patches’에 대한 자세한 내용을 참조하십시오.
\n장고의 문서는 훌륭하지만 항상 개선될 수 있습니다. 오타를 찾았나요? 당신은 무언가가 명확해져야 한다고 생각하나요? 문서 패치를 제안해 보십시오! :doc:’writing-documentation’의 가이드도 참조하십시오.
\n\n사용자가 작성하는 코드는 사용자 또는 사용자의 것입니다. 기여가 코드 한두 줄 이상이면 ‘CLA’에 서명해야 합니다. 자세한 설명은 기여자 사용권 계약 FAQ_를 참조하십시오.
\n큰 프로젝트에 새로 온 사람은 좌절감을 느끼기 쉽습니다. 여기 장고에 대한 여러분의 작업을 더 유용하고 보람 있게 만들기 위한 몇 가지 조언이 있습니다.
\nThis should be something that you care about, that you are familiar with or\nthat you want to learn about. You don’t already have to be an expert on the\narea you want to work on; you become an expert through your ongoing\ncontributions to the code.
\n트랙은 절대적인 것이 아닙니다. 문맥은 단어만큼 중요합니다. 트랙을 읽을 때, 여러분은 누가 어떤 말을 하는지, 언제 어떤 말을 했는지 고려해야 합니다. 2년 전 아이디어에 대한 지원이 반드시 그 아이디어가 여전히 지지를 받는다는 것을 의미하지는 않습니다. 여러분은 또한 누가 말을 하지 않았는지도 관심을 가질 필요가 있습니다. 예를 들어, 경험 많은 기여자가 최근에 토론에 참여하지 않았다면, 티켓은 장고에 들어가는 데 필요한 지원을 받지 못할 수도 있습니다.
\n큰 문제보다 작은 문제에 대한 피드백을 받는 것이 더 쉽습니다. ‘쉬운 선택’을 참조하십시오.
\n즉, 문제를 수정하기 전에 다른 사람이 버그가 실제인지 확인하도록 하고, 버그를 구현하기 전에 제안된 기능에 대한 합의가 있는지 확인하는 것입니다.
\n때때로 자신의 의견을 세상에 내놓고 “이 표는 정확하다”거나 “이 패치는 작업이 필요하다”고 말하는 것이 두려울 수 있지만, 이것은 프로젝트가 앞으로 나아갈 수 있는 유일한 방법입니다. 넓은 장고 공동체의 기여는 궁극적으로 한 사람의 기여보다 훨씬 더 큰 영향을 미칩니다. 여러분이 없이는 못 합니다!
\nIf you’re really not certain if a ticket is ready, don’t mark it as such. Leave\na comment instead, letting others know your thoughts. If you’re mostly certain,\nbut not completely certain, you might also try asking on the\n#contributing-getting-started channel in the Django Discord server to\nsee if someone else can confirm your suspicions.
티켓 한 장 또는 두 장에 집중하여 처음부터 끝까지 보고 반복합니다. 많은 표를 가지고 어떤 사람들은 도중에 넘어지게 하는 산탄총 같은 접근법은 결국 득보다 실이 더 많습니다.
\nWhen we say “PEP 8, and must have docs and tests”, we mean it. If a patch\ndoesn’t have docs and tests, there had better be a good reason. Arguments like\n“I couldn’t find any existing tests of this feature” don’t carry much weight.\nWhile it may be true, that means you have the extra-important job of writing\nthe very first tests for that feature, not that you get a pass from writing\ntests altogether.
\n티켓이나 패치가 빠르게 검토되는 것이 항상 쉬운 것은 아닙니다. 이건 개인적인 일이 아니에요. 통과하기 위해 많은 티켓과 풀 요청이 있습니다.
\n패치를 최신 상태로 유지하는 것이 중요합니다. 모든 검토 코멘트를 처리한 후 Trac에서 티켓을 검토하여 테스트 필요, 문서 필요 및 패치 개선 필요 플래그가 선택 취소되었는지 확인하십시오.
\nRemember that Django has an eight-month release cycle, so there’s plenty of\ntime for your patch to be reviewed.
\n마지막으로, 적절한 시기에 상기시키는 것이 도움이 될 수 있습니다. 아이디어에 대한 자세한 내용은:ref:’코드 기여 FAQ’를 참조하십시오.
\n