자주 묻는 질문 : 코드에 기여하기

제가 Django의 코드에 기여하려면 어떻게 해야할까요?

질문해 주셔서 감사합니다! 저희는 이 질문에 답하기 위해 문서도 마련해 놓았답니다. 문서의 제목은 Django에 기여하기 입니다.

몇 주 전에 버그 수정을 제출했습니다. 왜 내 기여를 무시하고 있습니까?

걱정마세요. 저희는 당신을 무시하고있지 않습니다!

‘티켓이 무시되는것’과 ‘티켓이 아직 올라오지 못한것’에 대한 차이점을 아는것이 중요합니다. Django 티켓 시스템은 실 사용자의 기능성에 다양한 영향을 주는 수백개의 오픈 티켓을 가지고 있습니다. 그래서 Django 개발자들은 그것들을 다시 살펴보고 우선순위를 나누어야 합니다.

가장 먼저, Django를 위해서 힘써주시는 모든 사람들은 자원봉사자입니다. 따라서 이 프레임워크를 위해 일할 수 있는 시간은 제한적일 수밖에 없을 뿐더러, 여유 시간에 따라 매주 변합니다. 만약 저희들이 바쁘면, 저희들이 원하는 만큼 Django에 시간을 투자하지 못할 수 있습니다.

티켓들이 지연되지 않고 체크인 되기위한 가장 좋은 방법은 그 분야의 코드에 친숙하지 않은 사람도 이해하고, 개선사항을 확인할 수 있도록 굉장히 쉽게 만드는 것입니다.

• 버그를 만들기 위한 정확한 지침이 있나요? 만약 이것이 Pillow와 같은 의존성이나 contrib 모듈 혹은 특정 데이터베이스를 다룬다면 친숙하지 않은 사람도 명확히 이해할 만한 지침이 있나요?

• 티켓에 연결된 여러 지점이 있는 경우 무시할 수 있는 지점 및 중요한 지점이 명확합니까?

• 변경 사항에 단위 테스트가 포함됩니까? 그렇지 않다면 왜 그렇지 않은지에 대한 명확한 설명이 있습니까? 테스트는 문제가 무엇인지 간결하게 표현하고 분기가 실제로 문제를 해결한다는 것을 보여줍니다.

기여가 Django에 포함되기에 적합하지 않다고 판단되면, 이를 무시하지 않고 티켓을 닫습니다. 따라서 티켓이 계속 열려 있는 경우는 기여를 무시한 것이 아니라, 아직 검토할 시간이 없었음을 의미합니다.

중요하게 생각하는 변경 사항을 언제, 어떤 방식으로 팀에 상기시키면 좋을까요?

포럼이나 브랜치에 적절한 시기에 정중한 메시지를 남기는 것은 주의를 끌 수 있는 한 가지 방법입니다. 적절한 시점을 판단하려면 일정을 계속해서 살펴보아야 합니다. 릴리스 마감 직전에 메시지를 게시할 경우, 원하는 방식으로 주의를 끌기 어려울 수 있습니다.

`Django Discord server`_의 ``#contributing-getting-started``채널에서 정중한 리마인더를 남기는 것도 도움이 될 수 있습니다.

관심을 끌 수 있는 또 다른 방법은 연관된 여러 개의 관련 티켓을 하나로 모으는 것입니다. 어떤 사람이 앉아서 일정 기간 다루지 않았던 부분의 버그를 확인할 때, 코드가 어떻게 작동하는지 세세하게 기억하는데 몇 분이 소요될 수 있습니다. 따라서 만약 당신이 여러 버그 픽스들을 비슷한 테마 그룹에 정리해 둔다면, 그것은 해당 부분 코드에 익숙해지는 과정이 여러 번 필요하지 않기 때문에 매력적인 타겟이 될 것입니다.

개인적으로 이메일을 보내거나 같은 이슈를 반복해서 제기하는 것을 자제해주시길 바랍니다. 이런 행동은 당신이 말하고자 하는 이슈가 다루어지는 것에 대한 관심을 끄는 데 전혀 도움이 되지 않습니다.

여러 차례 다시 알렸음에도 기여가 계속 무시되고 있습니다.

진지하게 말씀드리자면, 기여를 무시하고 있는 것이 아닙니다. 기여가 Django에 포함되기에 적합하지 않다고 판단되면 이를 무시하는 대신 티켓을 닫습니다. 그 외의 티켓에 대해서는 작업의 우선순위를 정해야 합니다. 이에 따라 일부 티켓은 다른 티켓보다 먼저 처리될 수 있습니다.

버그 픽스를 하는데 있어서 기준 중 하나는 해당 버그에 영향을 받을 사람들의 수 입니다. 많은 사람들에게 영향을 줄 수 있는 잠재력을 가지고있는 버그는 다른 버그들에 비해 높은 우선순위를 가집니다.

버그가 일정 기간 동안 무시될 수 있는 또 다른 이유는 해당 버그가 더 큰 문제의 증상일 수 있기 때문입니다. 여러 변경 사항을 작성하고 테스트하며 적용하는 데 시간을 쓸 수도 있지만, 경우에 따라서는 재구축이 올바른 해결책일 수 있습니다. 특정 컴포넌트의 재구축이나 리팩토링이 제안되었거나 이미 진행 중인 경우, 해당 컴포넌트에 영향을 미치는 버그들은 상대적으로 덜 주목받게 됩니다. 다시 말해, 이는 제한된 자원을 어떻게 우선순위에 따라 배분하느냐의 문제입니다. 재구축에 집중하면 자잘한 버그들을 한 번에 해결할 수 있을 뿐만 아니라 향후 다른 버그가 발생하는 것까지 예방할 수 있습니다.

이유가 무엇이든 간에, 당신이 어떤 버그를 주기적으로 발생시킨다고 해서 다른 장고 유저들 모두가 같은 버그를 발생시키지 않는다는 것을 알아야 합니다. 장고를 사용하는 사람들 각각은 서로 다른 환경에서 서로 다른 부분의 코드를 강조하여 장고를 다른 방식으로 장고를 사용합니다. 저희가 상대적인 우선 순위를 정할 때에는, 일반적으로 특정 한 사용자의 영향을 우선시하기보다는 전체 커뮤니티의 요구를 반영하려고 노력합니다. 이것은 당신이 가지고 있는 문제가 중요하지 않다는 의미가 아니라, 저희가 가지고 있는 시간이 제한되어 있기 때문입니다. 저희들은 항상 한 사람을 행복하게 하기보다 10명을 행복하게 하는 잘못을 범하고 있습니다.

100% 완벽하다고 확신할 수 있는 티켓을 직접 “체크인 준비 완료”로 표시할 수 있습니까?

죄송합니다. 티켓을 확인해 줄 다른 사람을 찾는 것이 무조건 더 좋습니다. 다른 사람을 찾는 데 문제가 있는 경우 위의 질문을 참조하세요.