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

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

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

I submitted a bug fix several weeks ago. Why are you ignoring my contribution?

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

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

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

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

• 버그를 만들기 위한 정확한 지침이 있나요? 만약 이것이 Pillow와 같은 의존성이나 contrib 모듈 혹은 특정 데이터베이스를 다룬다면 친숙하지 않은 사람도 명확히 이해할 만한 지침이 있나요?
• If there are several branches linked to the ticket, is it clear what each one does, which ones can be ignored and which matter?
• Does the change include a unit test? If not, is there a very clear explanation why not? A test expresses succinctly what the problem is, and shows that the branch actually fixes it.

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 또한 좋습니다. 다시 한 번 말씀드리지만, 계획적인 시간이 중요합니다. 예를 들면, 버그 수집 기간이 가장 좋을것입니다.

Another way to get traction is to pull several related tickets together. When someone sits down to review a bug in an area they haven’t touched for a while, it can take a few minutes to remember all the fine details of how that area of code works. If you collect several minor bug fixes together into a similarly themed group, you make an attractive target, as the cost of coming up to speed on an area of code can be spread over multiple tickets.

Please refrain from emailing anyone personally or repeatedly raising the same issue over and over again. This sort of behavior will not gain you any additional attention – certainly not the attention that you need in order to get your issue addressed.

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% 완벽하다고 확신할 수 있는 티켓을 직접 “체크인 준비 완료”로 표시할 수 있습니까?

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