자주 묻는 질문 : 코드에 기여하기¶
제가 Django의 코드에 기여하려면 어떻게 해야할까요?¶
질문해 주셔서 감사합니다! 저희는 이 질문에 답하기 위해 문서도 마련해 놓았답니다. 문서의 제목은 Django에 기여하기 입니다.
몇 주 전에 버그 수정을 제출했습니다. 왜 내 기여를 무시하고 있습니까?¶
걱정마세요. 저희는 당신을 무시하고있지 않습니다!
‘티켓이 무시되는것’과 ‘티켓이 아직 올라오지 못한것’에 대한 차이점을 아는것이 중요합니다. Django 티켓 시스템은 실 사용자의 기능성에 다양한 영향을 주는 수백개의 오픈 티켓을 가지고 있습니다. 그래서 Django 개발자들은 그것들을 다시 살펴보고 우선순위를 나누어야 합니다.
가장 먼저, Django를 위해서 힘써주시는 모든 사람들은 자원봉사자입니다. 따라서 이 프레임워크를 위해 일할 수 있는 시간은 제한적일 수밖에 없을 뿐더러, 여유 시간에 따라 매주 변합니다. 만약 저희들이 바쁘면, 저희들이 원하는 만큼 Django에 시간을 투자하지 못할 수 있습니다.
티켓들이 지연되지 않고 체크인 되기위한 가장 좋은 방법은 그 분야의 코드에 친숙하지 않은 사람도 이해하고, 개선사항을 확인할 수 있도록 굉장히 쉽게 만드는 것입니다.
버그를 만들기 위한 정확한 지침이 있나요? 만약 이것이 Pillow와 같은 의존성이나 contrib 모듈 혹은 특정 데이터베이스를 다룬다면 친숙하지 않은 사람도 명확히 이해할 만한 지침이 있나요?
티켓에 연결된 여러 지점이 있는 경우 무시할 수 있는 지점 및 중요한 지점이 명확합니까?
변경 사항에 단위 테스트가 포함됩니까? 그렇지 않다면 왜 그렇지 않은지에 대한 명확한 설명이 있습니까? 테스트는 문제가 무엇인지 간결하게 표현하고 분기가 실제로 문제를 해결한다는 것을 보여줍니다.
If your contribution is not suitable for inclusion in Django, we won’t ignore it – we’ll close the ticket. So if your ticket is still open, it doesn’t mean we’re ignoring you; it just means we haven’t had time to look at it yet.
When and how might I remind the team of a change I care about?¶
A polite, well-timed message in the forum/branch is one way to get attention. To determine the right time, you need to keep an eye on the schedule. If you post your message right before a release deadline, you’re not likely to get the sort of attention you require.
친절한 IRC 또한 좋습니다. 다시 한 번 말씀드리지만, 계획적인 시간이 중요합니다. 예를 들면, 버그 수집 기간이 가장 좋을것입니다.
관심을 끌 수 있는 또 다른 방법은 연관된 여러 개의 관련 티켓을 하나로 모으는 것입니다. 어떤 사람이 앉아서 일정 기간 다루지 않았던 부분의 버그를 확인할 때, 코드가 어떻게 작동하는지 세세하게 기억하는데 몇 분이 소요될 수 있습니다. 따라서 만약 당신이 여러 버그 픽스들을 비슷한 테마 그룹에 정리해 둔다면, 그것은 해당 부분 코드에 익숙해지는 과정이 여러 번 필요하지 않기 때문에 매력적인 타겟이 될 것입니다.
개인적으로 이메일을 보내거나 같은 이슈를 반복해서 제기하는 것을 자제해주시길 바랍니다. 이런 행동은 당신이 말하고자 하는 이슈가 다루어지는 것에 대한 관심을 끄는 데 전혀 도움이 되지 않습니다.
But I’ve reminded you several times and you keep ignoring my contribution!¶
Seriously - we’re not ignoring you. If your contribution is not suitable for inclusion in Django, we will close the ticket. For all the other tickets, we need to prioritize our efforts, which means that some tickets will be addressed before others.
버그 픽스를 하는데 있어서 기준 중 하나는 해당 버그에 영향을 받을 사람들의 수 입니다. 많은 사람들에게 영향을 줄 수 있는 잠재력을 가지고있는 버그는 다른 버그들에 비해 높은 우선순위를 가집니다.
Another reason that a bug might be ignored for a while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little changes, 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.
이유가 무엇이든 간에, 당신이 어떤 버그를 주기적으로 발생시킨다고 해서 다른 장고 유저들 모두가 같은 버그를 발생시키지 않는다는 것을 알아야 합니다. 장고를 사용하는 사람들 각각은 서로 다른 환경에서 서로 다른 부분의 코드를 강조하여 장고를 다른 방식으로 장고를 사용합니다. 저희가 상대적인 우선 순위를 정할 때에는, 일반적으로 특정 한 사용자의 영향을 우선시하기보다는 전체 커뮤니티의 요구를 반영하려고 노력합니다. 이것은 당신이 가지고 있는 문제가 중요하지 않다는 의미가 아니라, 저희가 가지고 있는 시간이 제한되어 있기 때문입니다. 저희들은 항상 한 사람을 행복하게 하기보다 10명을 행복하게 하는 잘못을 범하고 있습니다.
100% 완벽하다고 확신할 수 있는 티켓을 직접 “체크인 준비 완료”로 표시할 수 있습니까?¶
죄송합니다. 티켓을 확인해 줄 다른 사람을 찾는 것이 무조건 더 좋습니다. 다른 사람을 찾는 데 문제가 있는 경우 위의 질문을 참조하세요.
