버그 리포트와 기능 개발 요청

중요

보안 관련 이슈는 “반드시” [e-mail]. 에만 연락 주시기 바랍니다. 이는 쟝고 개발자들 중에서도 최고 수준 개발자들에게만 오랫동안 열려 있는 비공개 목록이며, 이에 대한 내용은 대중에 공개되지 않습니다. 좀 더 상세한 정보들은 :doc:` 우리의 보안 정책 </internals/security>` 문서를 참조하시기 바랍니다.

그렇지 않으면, `ticket tracker <https://code.djangoproject.com/>`_에 버그를 보고하거나 새로운 기능을 요청할 때, 다음과 같은 사항을 고려해주시기 바랍니다.

• 누군가 이미 버그나 기능요청을 티켓 트래커에 `searching`_나 진행중인 `custom queries`_로 제출하지 않았는지를 확인합니다.
• 지원 요청 질문들을 티켓시스템에 사용하지 마십시오. django-users 리스트나, #django IRC채널을 이용하시기 바랍니다.
• |django-developers|와의 합의점을 찾지 않은 채로 “wontfix”로 마크된 이슈들을 다시 열지 마십시오.
• 긴 논의사항에 티켓 추적기를 사용하지 마십시오. 방향을 잃을 수 있습니다. 특정 티켓이 논란이 된다면 논의사항을 |django-developers|로 옮겨주세요.

버그 리포팅

잘 쓰여진 버그 리포트들은 믿을수없을 정도로 유용합니다. 그러나 어떠한 버그 트래킹 시스템 작업들을 사용하는것들도 일정량의 오버헤드가 수반되므로 티켓 트래커를 최대한 유용하게 보관해 주시기 바랍니다

• 당신의 이슈가 잘 알려진 문제인지 보고싶다면 FAQ 1 를 꼭 읽어주세요
• 만약 당신이 보고있는것이 버그인지 확신할 수 없다면, 꼭 django-users 나 #django 에 먼저 물어봐주세요.
• 완전하고, 재현가능하고, 특정한 버그 리포트를 꼭 쓰시오. 문제에 대한 명확하고 간결한 설명과 문제를 재현하기 위한 지시사항을 포함해야 합니다. 코드 스니펫, 테스트 사례, 예외 백트레이스, 스크린샷 등과 같은 디버그 정보를 최대한 많이 추가세요. 작고 멋진 테스트 케이스는 버그를 신속하게 확인할 수 있는 유용한 방법을 제공하기 때문에 버그를 보고하는 가장 좋은 방법입니다.
• 버그 보고서를 제출했다는 것을 알리기 위해 |django-developers|에 게시하지 마십시오. 모든 티켓은 다른 목록인 |django-updates|로 전송되며, 이 목록은 개발자와 관심 있는 커뮤니티 구성원에 의해 추적됩니다. 우리는 티켓이 파일된 것을 볼 수 있습니다.

작성하신 티켓의 라이프사이클을 확인하시려면 다음 문서를 참조해 주세요 티켓 분류.

사용자 인터페이스 와 기능 버그 리포팅

버그나 기능 요청이 시각적인 성질을 건드리는 경우 따라야 할 몇 가지 추가 지침이 있습니다.

• 티켓에 최소한의 테스트 사례와 동등한 시각적 스크린샷을 포함하십시오. 당신이 당신의 브라우저에 만든 별난 커스터마이징이 아닌, 문제를 보이십시오
• 스틸컷을 이용해 문제를 보이기가 어려울경우, 간단한 스크린 캐스트를 캡처하는것을 고려하십시오. 소프트웨어에서 허용하는 경우 화면의 관련 영역만 캡처합니다.
• Django의 UI의 모양이나 행위를 변경하는 패치를 제공하는 경우 이전*과* 이후의 스크린샷/스크린캐스트를 반드시 첨부해야 합니다. 이것들이 없는 티켓은 분류자들이 빨리 평가하기가 어렵다.
• 스크린샷이 리포팅에 필요한 다른 양식들을 면제해주지는 않습니다. 스크린샷에 보이는 행위를 재현하는 방법에 대한 URL, 코드 조각 및 단계적 지시들을 포함해야 합니다.
• 관심 있는 사람들이 티켓을 찾을 수 있도록 티켓에 UI/UX 플래그를 설정해야 합니다.

기능 요청

우리는 항상 Django를 더 좋게 만들기 위해 노력하고 있고, 이 부분에 있어 당신의 기능 요청은 매우 중요합니다. 다음은 요청을 가장 효과적으로 기능을 요청하는 방법에 대한 몇 가지 팁입니다

• 기능을 사용하려면 장고의 코어 변경이 필요한 경우를 확실히 하십시오. 예를 들어, 다른 데이터베이스 엔진을 지원하려는 경우처럼 아이디어를 독립적인 애플리케이션이나 모듈로 개발할 수 있다면, 독자적으로 개발할 것을 제안할 것입니다. 그리고 난 후 당신의 프로젝트가 커뮤니티의 충분한 지지를 받는다면, 우리는 그것을 장고에 포함시키는 것을 고려할 수 있습니다.
• 먼저 티켓 트래커가 아닌 django-developers 목록에 있는 기능을 요청하십시오. 메일링 리스트에 있으면 더 자세히 읽을 수 있을 것입니다. 이는 대규모 기능 요청의 경우 훨씬 더 중요합니다. 우리는 실제로 장고의 핵심을 작업하기 전에 메일링 리스트에 있는 장고의 핵심에 대한 큰 변화에 대해 논의하고는 합니다.
• 누락된 기능이 무엇인지, 그리고 어떻게 구현하고 싶은지 명확하고 간결하게 설명하십시오. 가능한 경우 예제 코드(함수형태가 아니어도 괜찮음)를 포함하십시오.
• 이 기능을 원하는 *이유*에 대해 설명합니다. 최소한의 사용 경우를 설명하면 다른 사람이 해당 사용 사례가 어디에 적합한지, 그리고 동일한 사용 사례를 달성하는 다른 방법이 이미 있는지 이해하는 데 도움이 될 것입니다.

기능에 대한 동의가 있으면 티켓을 생성하는 것이 적절합니다. 티켓 설명에 |django-developers|의 토론 링크를 포함시키세요.

대부분의 오픈소스 프로젝트와 마찬가지로 코드 토크도 있습니다. 기능에 대한 코드를 직접 작성할 의향이 있거나, 이미 작성한 경우 훨씬 더 받아들여질 가능성이 높습니다. GitHub에서 Django를 포크하고 기능 브랜치를 생성한 다음 당신의 작품을 보여주세요!

이곳도 확인하세요: 새로운 기능을 문서화합니다..

의사 결정 방법

우리는 가능한 한 대략적인 합의를 위해 노력합니다. 이를 위해 기능에 대한 비공식 투표를 django-developers 에서 실시합니다. 이 투표에서 우리는 Apache에 의해 발명되고 Python 자체에 사용되는 투표 스타일을 따릅니다. 여기서 투표는, +1, +0, -0 또는 -1로 주어집니다. 이 표의 의미는 다음과 같습니다.

• +1: “저는 그 아이디어를 매우 좋아하고 그것에 강하게 전념하고 있습니다.”
• +0: “괜찮을 것 같네요.”
• -0: “저는 흥미롭진 않지만, 반대하지는 않을 것입니다.”
• : “저는 그 생각이 현실로 바뀌는 것을 보는 것에 강하게 반대하며 매우 불행할 것입니다.”

비록 |django-developers|에서의 투표는 비공식적이지만, 그들은 매우 심각하게 받아들여질 것입니다. 적절한 투표 기간을 거친 후, 명백한 합의가 이루어지면 우리는 투표 결과를 따를 것입니다.

그러나 합의가 항상 가능한 것은 아닙니다. 합의에 이르지 못하거나 합의를 위한 논의가 구체적인 결정 없이 흐지부지될 경우 결정은:ref:`technical board `로 연기될 수 있습니다.

내부적으로 기술 위원회는 동일한 투표 메커니즘을 사용할 것입니다. 다음과 같은 경우 제안은 이행된 것으로 간주됩니다.

• 기술 위원회 구성원들로부터 최소 3개의 “+1” 표가 있습니다.
• 기술 이사회의 어떤 구성원도 “-1” 투표를 하지 않습니다.

투표는 일주일 이내에 제출해야 합니다.

이 과정은 기술 이사국이라면 누구나 제안을 거부할 수 있기 때문에, “-1” 표결은 해당 “-1”을 최소한 “+0”으로 변환하는 데 필요한 사항에 대한 설명을 수반해야 합니다.

기술 문제에 대한 투표는 django-developers 메일링 목록에서 발표되고 공개되어야 합니다.