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

중요

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

버그 리포팅

Before reporting a bug on the ticket tracker consider these points:

• Check that someone hasn’t already filed the bug report by searching or running custom queries in the ticket tracker.

• Don’t use the ticket system to ask support questions. Use the Django Forum or the Django Discord server for that.

• Don’t reopen issues that have been marked “wontfix” without finding consensus to do so on the Django Forum.

• Don’t use the ticket tracker for lengthy discussions, because they’re likely to get lost. If a particular ticket is controversial, please move the discussion to the Django Forum.

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

• 당신의 이슈가 잘 알려진 문제인지 보고싶다면 FAQ 1 를 꼭 읽어주세요

• Do ask on Django Forum or the Django Discord server first if you’re not sure if what you’re seeing is a bug.

• 완전하고, 재현가능하고, 특정한 버그 리포트를 꼭 쓰시오. 문제에 대한 명확하고 간결한 설명과 문제를 재현하기 위한 지시사항을 포함해야 합니다. 코드 스니펫, 테스트 사례, 예외 백트레이스, 스크린샷 등과 같은 디버그 정보를 최대한 많이 추가세요. 작고 멋진 테스트 케이스는 버그를 신속하게 확인할 수 있는 유용한 방법을 제공하기 때문에 버그를 보고하는 가장 좋은 방법입니다.

• Don’t post to Django Forum only to announce that you have filed a bug report. All the tickets are mailed to another list, django-updates, which is tracked by developers and interested community members; we see them as they are filed.

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

Reporting user interface bugs

If your bug impacts anything visual in nature, there are a few additional guidelines to follow:

• Include screenshots in your ticket which are the visual equivalent of a minimal test case. Show off the issue, not the crazy customizations you’ve made to your browser.

• 스틸컷을 이용해 문제를 보이기가 어려울경우, 간단한 스크린 캐스트를 캡처하는것을 고려하십시오. 소프트웨어에서 허용하는 경우 화면의 관련 영역만 캡처합니다.

• If you’re offering a patch that changes the look or behavior of Django’s UI, you must attach before and after screenshots/screencasts. Tickets lacking these are difficult for triagers to assess quickly.

• 스크린샷이 리포팅에 필요한 다른 양식들을 면제해주지는 않습니다. 스크린샷에 보이는 행위를 재현하는 방법에 대한 URL, 코드 조각 및 단계적 지시들을 포함해야 합니다.

• 관심 있는 사람들이 티켓을 찾을 수 있도록 티켓에 UI/UX 플래그를 설정해야 합니다.

기능 요청

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

• Evaluate whether the feature idea requires changes in Django’s core. If your idea can be developed as an independent application or module — for instance, you want to support another database engine — we’ll probably suggest that you develop it independently. Then, if your project gathers sufficient community support, we may consider it for inclusion in Django.

• Propose the feature in the new feature ideas GitHub project (not in the ticket tracker) by creating a new item in the Idea column. This is where the community and the Steering Council evaluate new ideas for the Django ecosystem. This step is especially important for large or complex proposals. We prefer to discuss any significant changes to Django’s core before any development begins. In some cases, a feature may be better suited as a third-party package, where it can evolve independently of Django’s release cycle.

• 누락된 기능이 무엇인지, 그리고 어떻게 구현하고 싶은지 명확하고 간결하게 설명하십시오. 가능한 경우 예제 코드(함수형태가 아니어도 괜찮음)를 포함하십시오.

• 이 기능을 원하는 *이유*에 대해 설명합니다. 최소한의 사용 경우를 설명하면 다른 사람이 해당 사용 사례가 어디에 적합한지, 그리고 동일한 사용 사례를 달성하는 다른 방법이 이미 있는지 이해하는 데 도움이 될 것입니다.

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

Requesting performance optimizations

Reports of a performance regression, or suggested performance optimizations, should provide benchmarks and commands for the ticket triager to reproduce.

See the django-asv benchmarks for more details of Django’s existing benchmarks.

의사 결정 방법

Whenever possible, we aim for rough consensus. Emoji reactions are used on issues within the new feature ideas GitHub project to track community feedback. The following meanings are assigned to each reaction:

• 👍: I support this feature and would use it

• 👎: I oppose this feature or believe it would cause issues for me or Django

• 😕: I have no strong opinion on this feature

• 🎉: This feature seems like a straightforward and beneficial addition

The Steering Council will regularly review the ideas in the project, moving those with community support through the following stages:

• Idea

• Approved - Idea refinement - Team creation

• In progress

• Working solution - Review - Feedback

• Needs maintainer (Django only)

• Done

Occasionally, discussions on feature ideas or the direction of Django may take place on the Django Forum. These discussions may include informal votes, which follow the voting style invented by Apache and used on Python itself, where votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:

• +1: “저는 그 아이디어를 매우 좋아하고 그것에 강하게 전념하고 있습니다.”

• +0: “괜찮을 것 같네요.”

• -0: “저는 흥미롭진 않지만, 반대하지는 않을 것입니다.”

• : “저는 그 생각이 현실로 바뀌는 것을 보는 것에 강하게 반대하며 매우 불행할 것입니다.”

Although these votes are informal, they’ll be taken very seriously. After a suitable voting period, if an obvious consensus arises we’ll follow the votes.