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

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

질문 주셔서 감사합니다! 이 질문에 대한 전체 문서를 작성했습니다. 그것은 제목이 Django에 기여하기.

몇 주 전에 티켓 시스템에 버그 수정을 제출했습니다. 왜 내 패치를 무시하니?

걱정하지 마라. 우리는 당신을 무시하지 않고있다!

“티켓은 무시되고” “티켓에는 아직 참석하지 않았습니다.”라는 차이점을 이해하는 것이 중요합니다. Django의 티켓 시스템에는 최종 사용자 기능에 다양한 영향을 미치는 수백 개의 티켓이 포함되어 있으며 Django 개발자는 검토하고 우선 순위를 지정해야합니다.

그것의 꼭대기에: Django에서 일하는 사람들은 모두 자원 봉사자입니다. 따라서 프레임 워크에서 작업해야하는 시간은 제한적이며 여가 시간에 따라 주마다 다를 수 있습니다. 우리가 바쁘다면 우리는 Django에 대해 많은 시간을 할애하지 못할 수도 있습니다.

티켓을 체크인하는 동안 방해받지 않도록하는 가장 좋은 방법은 코드의 해당 영역을 잘 알고 있지 않은 사람이라 할지라도 문제를 이해하고 수정 사항을 확인하기 쉽도록 죽이는 것입니다.

  • 버그를 재현하는 방법에 대한 명확한 지침이 있습니까? 이것이 의존성 (베개 같은), 기여 모듈 또는 특정 데이터베이스와 접촉한다면, 익숙하지 않은 사람들을 위해서조차도 그러한 지시가 명확한가?

  • 티켓에 첨부 된 패치가 여러 개인 경우 각 패치가 수행하는 작업이 무엇인지, 어떤 내용을 무시할 수 있는지, 그리고 어떤 문제가 있는지를 명확히 밝혀야합니까?

  • 패치에 단위 테스트가 포함되어 있습니까? 그렇지 않다면 아주 명확한 이유가 있습니까? 테스트는 문제가 무엇인지 간결하게 표현하고 패치로 실제로 수정되었음을 보여줍니다.

패치가 Django에 포함될 가능성이 없다면, 우리는 그것을 무시하지 않을 것입니다 - 우리는 단지 티켓을 닫을 것입니다. 그래서 티켓이 아직 열려 있다면, 우리가 당신을 무시한다는 것을 의미하지는 않습니다. 그것은 우리가 아직 그것을 볼 시간이 없다는 것을 의미합니다.

핵심 팀에게 언제 내가 신경 써야 할 패치를 상기 시켜줄 수 있습니까?

메일 링리스트에 정중하고 시간을 초월한 메시지는 관심을 끄는 한 가지 방법입니다. 적절한 시간을 결정하려면 일정을 주시해야합니다. 핵심 개발자가 마감 기한을 맞추거나 계획 단계를 관리하려고 할 때 메시지를 게시하면 원하는주의를 끌지 못할 것입니다. 그러나 핵심 개발자가 버그에 특히주의를 기울일 때 티켓에주의를 끌면 버그 수정 전이나 예를 들어 베타 버전 출시 전까지는 티켓을 얻을 확률이 훨씬 더 높습니다. 생산적인 반응.

적절한 IRC 알리미는 또한 가능하면 전략적으로 다시 작동합니다. 버그 스프린트 동안 예를 들어, 아주 좋은 시간이 될 것입니다.

견인력을 얻는 또 다른 방법은 여러 관련 티켓을 함께 가져 오는 것입니다. 핵심 개발자가 잠시 동안 만진 적이없는 영역에서 버그를 수정하기 위해 앉아있을 때 코드 영역이 어떻게 작동하는지 모든 세부 정보를 기억하는 데 몇 분이 걸릴 수 있습니다. 비슷한 주제 그룹에 여러 개의 작은 버그 수정을 모으는 경우 코드 영역에서 속도를 높이는 비용이 여러 티켓에 분산 될 수 있기 때문에 매력적인 대상을 만듭니다.

핵심 개발자에게 개인적으로 이메일을 보내거나 동일한 문제를 반복해서 제기하는 것은 삼가 주시기 바랍니다. 이런 종류의 행동은 당신에게 추가적인주의를주지는 않습니다 - 당신의 애완 동물 버그를 해결하기 위해 당신이 필요로하는 관심이 아닙니다.

하지만 나는 여러 번 생각 나게하고 내 패치를 무시하고있다!

진심으로 우리는 당신을 무시하지 않고 있습니다. 패치가 Django에 포함될 가능성이 없다면 티켓을 닫을 것입니다. 다른 모든 티켓의 경우 우선 순위를 정해야합니다. 즉, 일부 티켓은 다른 티켓보다 먼저 처리됩니다.

버그 수정의 우선 순위를 결정하는 데 사용되는 기준 중 하나는 특정 버그의 영향을받는 사용자 수입니다. 많은 사람들에게 영향을 줄 가능성이있는 버그는 일반적으로 엣지 케이스보다 우선 순위가 높습니다.

버그가 더 큰 문제의 증상 인 경우 버그가 무시 될 수있는 또 다른 이유가 있습니다. 우리는 시간을 들여 작은 패치를 많이 작성하고 테스트하고 적용 할 수 있지만 때때로 올바른 해결책은 다시 작성하는 것입니다. 특정 구성 요소의 재 작성 또는 리팩터링이 제안되었거나 진행 중이면 해당 구성 요소에 영향을주는 버그가별로 주목받지 못할 수 있습니다. 다시 말하지만, 이것은 희소 자원의 우선 순위를 정하는 문제 일뿐입니다. 다시 빌드하는 데 집중함으로써 모든 작은 버그를 한꺼번에 닫을 수 있으며 앞으로 다른 작은 버그가 나타나지 않도록 할 수 있습니다.

그 이유가 무엇이든, 정기적으로 특정 버그를 치는 동안, 반드시 모든 단일 Django 사용자가 동일한 버그에 부딪 힐 것은 반드시 따르지는 않습니다. 다른 사용자들은 Django를 여러 가지 방법으로 사용합니다. 서로 다른 조건에서 코드의 다른 부분을 강조합니다. 상대적 우선 순위를 평가할 때 일반적으로 특정 사용자의 심각성뿐만 아니라 전체 커뮤니티의 요구 사항을 고려하려고합니다. 우리가 사용할 수있는 제한된 시간 내에 문제가 중요하지 않다고 생각하는 것은 아닙니다. 1 인을 행복하게 만드는 것보다 10 명의 사람들을 행복하게 만드는 측면에서 항상 잘못을 저지르는 것입니다.