# Django 2.1.8.dev20190330215650 documentation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

버그들이 무시되어질 수 있는 또 다른 이유는 버그가 큰 문제의 징후일 수 있기 때문입니다. 저희들이 굉장히 많은 작은 패치들을 작성하고 테스팅할 때, 가끔은 새로 빌드하는 것이 올바른 방법일 경우가 있습니다. 만약 특정 요소들을 새로 빌드하거나 재개발하는 것으로 결정되거나 진행중에 있다면, 해당 요소에 영향을 주는 버그들은 많은 관심을 받지 못할 것입니다. 다시한번 말씀드리면, 이것은 단지 적은 자원에 따른 우선순위를 정하는 문제입니다. 새로 빌드하는것에 집중하므로써, 저희들은 한번에 작은 버그들을 닫고, 미래에 발생할 작은 버그들을 방지할 수 있습니다.

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