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

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

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

티켓 시스템에 버그 수정 요청을 몇 주전에 했는데, 왜 해당 패치를 무시하고 있나요?

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

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

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

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

• 버그를 만들기 위한 정확한 지침이 있나요? 만약 이것이 Pillow와 같은 의존성이나 contrib 모듈 혹은 특정 데이터베이스를 다룬다면 친숙하지 않은 사람도 명확히 이해할 만한 지침이 있나요?
• 만약 티켓에 대한 여러가지의 패치들이 있다면, 각 패치들이 무엇을하고, 어떤것이 무시되고 어떤것이 중요한가요?
• 패치가 유닛 테스트를 포함하나요? 그렇지 않다면, 왜 그런지 명확한 설명이 있나요? 테스트는 문제점을 간단명료하게 표현하고 해당 패치가 문제를 고쳤다는 것을 보입니다.

만약 패치가 장고와 연관성이 없다면, 저희들은 그것을 무시하지 않고, 그 티켓을 닫습니다. 따라서 만약 티켓이 열린 상태라면, 우리가 당신을 무시하는것이 아니라, 그것을 살펴볼 시간이 아직 없었다는 것입니다.

언제 그리고 어떻게 팀에게 패치에 내가 관심을 가지고 있는지 상기시킬 수 있을까요?

메일링 리스트로 정중하고, 시기 적절한 메시지는 저희의 주의를 끌 수 있는 한 가지 방법입니다. 적절한 시간을 결정하기 위해서는 스케줄을 잘 살펴보아야 합니다. 만약 릴리즈 마감 바로직전에 메시지를 게시하였다면, 당신이 요청한 사항에 대한 관심을 받을 수 없을 것입니다.

친절한 IRC 또한 좋습니다. 다시한번 말씀드리지만, 계획적인 시간이 중요합니다. 예를 들면, 버그 수집 기간이 가장 좋을것입니다.

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

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

하지만 몇 차례에 걸쳐서 알려주었지만 계속 제가 올린 패치를 무시하고 있습니다!

진지하게, 저희는 당신을 무시하지 않습니다. 만약 당신의 패치가 장고와 관련이 없다면, 티켓을 닫습니다. 그 외 다른 티켓들은 어떤 티켓이 다른 티켓들보다 우선적으로 다뤄질 수 있도록 우선순위를 만듭니다.

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

Another reason that bugs might be ignored for while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little patches, sometimes the right solution is to rebuild. If a rebuild or refactor of a particular component has been proposed or is underway, you may find that bugs affecting that component will not get as much attention. Again, this is a matter of prioritizing scarce resources. By concentrating on the rebuild, we can close all the little bugs at once, and hopefully prevent other little bugs from appearing in the future.

Whatever the reason, please keep in mind that while you may hit a particular bug regularly, it doesn't necessarily follow that every single Django user will hit the same bug. Different users use Django in different ways, stressing different parts of the code under different conditions. When we evaluate the relative priorities, we are generally trying to consider the needs of the entire community, instead of prioritizing the impact on one particular user. This doesn't mean that we think your problem is unimportant -- just that in the limited time we have available, we will always err on the side of making 10 people happy rather than making a single person happy.