신규 기여자에 대한 조언¶

트라이아지 티켓

검토되지 않은 티켓에서 버그가 보고되면 다시 재생성해 보십시오. 만약 당신이 그것을 재현할 수 있고 그것이 유효해 보인다면, 버그를 확인했다는 것을 메모하고 티켓을 받아들입니다. 티켓이 올바른 구성 요소 영역 아래에 정리되어 있는지 확인하십시오. 버그 자체를 수정하지 않더라도 버그의 동작에 대한 테스트를 추가하는 패치를 작성하는 것을 고려해 보십시오. 자세한 내용은 다음 사이트를 참조하십시오.참조:어떻게 하면 트라이얼을 할 수 있을지

승인된 티켓을 찾고 패치를 검토하여 코드베이스 및 프로세스에 익숙해지도록 합니다

패치에 문서 또는 테스트가 필요한 경우 해당 플래그를 표시합니다. 패치가 변경한 내용을 살펴보고 이전 버전이지만 여전히 지원되는 Python 버전과 호환되지 않는 구문을 확인하십시오. :doc:’테스트’를 실행하여 테스트에 합격했는지 확인합니다. 가능한 경우 SQLite가 아닌 다른 데이터베이스에서 해당 파일을 사용해 보십시오. 댓글과 피드백을 남겨주세요!

이전 패치 최신 상태로 유지

종종 코드베이스는 제출되는 패치와 검토되는 시간 사이에서 변경됩니다. 여전히 깨끗하게 적용되고 예상대로 작동하는지 확인하십시오. 패치를 업데이트하는 것은 유용하고 중요합니다! :doc:’writing-code/submitting-patches’에 대한 자세한 내용을 참조하십시오.

설명서 작성

장고의 문서는 훌륭하지만 항상 개선될 수 있습니다. 오타를 찾았나요? 당신은 무언가가 명확해져야 한다고 생각하나요? 문서 패치를 제안해 보십시오! :doc:’writing-documentation’의 가이드도 참조하십시오.

기여자 사용권 계약서에 서명

사용자가 작성하는 코드는 사용자 또는 사용자의 것입니다. 기여가 코드 한두 줄 이상이면 ‘CLA’에 서명해야 합니다. 자세한 설명은 기여자 사용권 계약 FAQ_를 참조하십시오.

관심 있는 주제 영역, 친숙한 주제 또는 배우고 싶은 주제 영역을 선택합니다

당신은 당신이 작업하고 싶은 분야의 전문가일 필요는 없습니다. 당신은 코드에 대한 지속적인 기여를 통해 전문가가 됩니다.

티켓의 컨텍스트 및 기록 분석

트랙은 절대적인 것이 아닙니다. 문맥은 단어만큼 중요합니다. 트랙을 읽을 때, 여러분은 누가 어떤 말을 하는지, 언제 어떤 말을 했는지 고려해야 합니다. 2년 전 아이디어에 대한 지원이 반드시 그 아이디어가 여전히 지지를 받는다는 것을 의미하지는 않습니다. 여러분은 또한 누가 말을 하지 않았는지도 관심을 가질 필요가 있습니다. 예를 들어, 경험 많은 기여자가 최근에 토론에 참여하지 않았다면, 티켓은 장고에 들어가는 데 필요한 지원을 받지 못할 수도 있습니다.

소규모로 시작

큰 문제보다 작은 문제에 대한 피드백을 받는 것이 더 쉽습니다. ‘쉬운 선택’을 참조하십시오.

큰 작업에 참여하려면 먼저 아이디어를 지원해야 합니다

즉, 문제를 수정하기 전에 다른 사람이 버그가 실제인지 확인하도록 하고, 버그를 구현하기 전에 제안된 기능에 대한 합의가 있는지 확인하는 것입니다.

대담하게! 피드백을 남겨주세요!

때때로 자신의 의견을 세상에 내놓고 “이 표는 정확하다”거나 “이 패치는 작업이 필요하다”고 말하는 것이 두려울 수 있지만, 이것은 프로젝트가 앞으로 나아갈 수 있는 유일한 방법입니다. 넓은 장고 공동체의 기여는 궁극적으로 한 사람의 기여보다 훨씬 더 큰 영향을 미칩니다. 여러분이 없이는 못 합니다!

체크인 준비 완료 표시 시 주의 사항 오류 발생

티켓이 준비되었는지 확실하지 않으면 티켓으로 표시하지 마십시오. 대신 당신의 생각을 다른 사람에게 알리면서 댓글을 남기세요. 대부분 확실하지만 완전히 확실하지는 않은 경우 IRC에 다른 사람이 사용자의 의심을 확인할 수 있는지 문의해 볼 수도 있습니다.

피드백을 기다린 후 받은 피드백에 응답합니다

티켓 한 장 또는 두 장에 집중하여 처음부터 끝까지 보고 반복합니다. 많은 표를 가지고 어떤 사람들은 도중에 넘어지게 하는 산탄총 같은 접근법은 결국 득보다 실이 더 많습니다.

엄중해지세요

“:pep:’8’, 그리고 반드시 문서와 시험이 있어야 한다”는 말은, 우리는 그것을 의미합니다. 패치에 문서와 테스트가 없는 경우 타당한 이유가 있어야 합니다. “이 기능에 대한 기존 테스트를 찾을 수 없었습니다”와 같은 주장은 큰 중요성을 지니지 않습니다. 하지만 이는 여러분이 이 기능에 대한 첫 번째 테스트를 작성해야 하는 매우 중요한 일을 가지고 있다는 것을 의미하지만, 여러분이 쓰기 테스트에서 완전히 합격했다는 것은 아닙니다.

인내심을 가지세요

티켓이나 패치가 빠르게 검토되는 것이 항상 쉬운 것은 아닙니다. 이건 개인적인 일이 아니에요. 통과하기 위해 많은 티켓과 풀 요청이 있습니다.

패치를 최신 상태로 유지하는 것이 중요합니다. 모든 검토 코멘트를 처리한 후 Trac에서 티켓을 검토하여 테스트 필요, 문서 필요 및 패치 개선 필요 플래그가 선택 취소되었는지 확인하십시오.

Remember that Django has an eight-month release cycle, so there’s plenty of time for your patch to be reviewed.

마지막으로, 적절한 시기에 상기시키는 것이 도움이 될 수 있습니다. 아이디어에 대한 자세한 내용은:ref:’코드 기여 FAQ’를 참조하십시오.