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

중요

보안 관련 문제는 ``[e-mail]``**으로만** 보고해 주시기 바랍니다. 이 비공개 메일링 리스트는 오랫동안 활동해 온 신뢰받는 Django 개발자들에게만 열려 있으며, 아카이브는 공개되지 않습니다. 자세한 내용은 :doc:`our security policies </internals/security>`을 확인하세요.

버그 리포팅

`ticket tracker <https://code.djangoproject.com/>`_에 버그를 제보하기 전에 다음 사항을 고려해 주세요.

• 티켓 트래커에서 searching 또는 `custom queries`_를 사용하여 이미 동일한 버그 보고가 제출되지 않았는지 확인하세요.

• 지원 관련 질문에는 티켓 시스템을 사용하지 마세요. 대신 Django Forum`_ 또는 `Django Discord server`_를 이용하세요.

• `Django Forum`_에서 합의 없이 “wontfix”로 표시된 이슈를 다시 열지 마세요.

• new feature ideas GitHub 프로젝트를 통해 이슈를 진행하지 않고 “needsnewfeatureprocess”로 표시된 이슈를 다시 열지 마세요.

• 긴 논의에는 티켓 트래커를 사용하지 마세요. 내용이 파악하기 어려워질 수 있습니다. 특정 티켓에 대한 논의가 길어질 경우, 논의를 `Django Forum`_으로 옮겨주세요.

잘 작성된 버그 리포트는 매우 큰 도움이 됩니다. 그러나 어떤 버그 추적 시스템이든 일정한 관리 비용이 수반되므로, 티켓 트래커를 최대한 유용하게 유지하는 데 협조해 주시면 감사하겠습니다. 특히 다음 사항을 지켜주세요:

• 자신의 이슈가 잘 알려진 문제인지 확인하려면 :doc:`FAQ </faq/index>`를 반드시 읽어보세요.

• 보고 있는 내용이 버그인지 확신이 서지 않는다면 우선 Django Forum 또는 `Django Discord server`_에 문의하세요.

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

• 단순히 버그 보고서를 제출했다는 사실을 알리기 위한 목적으로 `Django Forum`_에 글을 게시하지 마세요. 모든 티켓은 |django-updates|라는 다른 메일링 리스트로 전송되며, 이 목록은 개발자와 관심 있는 커뮤니티 구성원이 확인하고 있습니다. 따라서 티켓이 제출되는 즉시 확인할 수 있습니다.

생성한 티켓의 처리 과정을 이해하려면 :ref:`triage-workflow`를 참고하세요.

사용자 인터페이스 버그 보고

버그가 시각적인 요소에 영향을 미치는 경우, 추가로 따라야 할 몇 가지 지침이 있습니다.

• 티켓에는 최소한의 테스트 케이스를 보여줄 수 있도록 스크린샷을 포함하세요. 브라우저의 과도한 개인 설정이 아닌, 문제 자체가 드러나는 화면을 보여주세요.

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

• Django UI의 모양이나 동작을 변경하는 패치를 제공하는 경우, 반드시 변경 전 및 변경 후 스크린샷이나 스크린캐스트를 첨부해야 합니다. 이러한 자료가 없는 티켓은 분류자가 빠르게 평가하기 어렵습니다.

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

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

• 접근성과 관련된 문제인 경우, 관련 accessibility standard 링크를 포함해 주세요.

기능 요청

우리는 항상 Django를 더 나은 방향으로 발전시키기 위해 노력하고 있으며, 여러분의 기능 요청은 그 핵심 부분입니다. 다음은 요청을 가장 효과적으로 작성하는 방법에 대한 몇 가지 팁입니다:

• 제안하는 기능이 Django 코어의 변경을 필요로 하는지 검토해 보세요. 다른 데이터베이스 엔진 지원과 같이 독립적인 애플리케이션이나 모듈로 개발 가능한 아이디어라면, 우선 독립적으로 개발해 볼 것을 권장합니다. 이후 해당 프로젝트가 커뮤니티의 충분한 지지를 얻게 된다면, Django에 포함하는 방안을 고려하겠습니다.

• 티켓 트래커가 아닌 new feature ideas GitHub 프로젝트의 Idea 열에 새 항목을 추가하여 기능을 제안하세요. 이곳은 커뮤니티와 :ref:`Steering Council <steering-council>`이 Django 생태계를 위한 새로운 아이디어를 검토하는 곳입니다. 제안 내용이 규모가 크거나 복잡할수록 이 단계는 특히 중요합니다. 개발을 시작하기 전에 Django 코어의 중요한 변경 사항은 충분히 논의하는 것을 선호합니다. 경우에 따라서는 기능이 Django 릴리스 주기와 독립적으로 발전할 수 있는 서드파티 패키지로 구현하는 것이 더 적합할 수 있습니다.

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

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

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

성능 최적화 요청

성능 저하 보고나 성능 최적화 제안 시에는 티켓 분류자가 재현할 수 있도록 벤치마크와 실행 명령을 제공해야 합니다.

Django의 기존 벤치마크에 대한 자세한 내용은 :ref:`django-asv-benchmarks`에서 확인할 수 있습니다.

의사 결정 방법

가능한 한 대략적인 합의를 지향합니다. new feature ideas GitHub 프로젝트의 이슈에서는 커뮤니티 피드백을 확인하기 위해 이모지 반응을 사용하며, 각 이모지의 의미는 다음과 같습니다.

• 👍: 이 기능을 지지하며 사용할 의향이 있습니다.

• 👎: 이 기능에 반대하거나, 사용자 또는 Django에 문제가 발생할 수 있다고 생각합니다.

• 😕: 이 기능에 대해 특별한 의견은 없습니다.

• 🎉: 이 기능은 구현이 간단하며 유용해 보입니다.

:ref:`Steering Council <steering-council>`은 프로젝트의 아이디어를 정기적으로 검토하고, 커뮤니티의 지지를 받은 아이디어를 다음 단계로 진행합니다.

• 아이디어

• 승인 - 아이디어 구체화 - 팀 구성

• 진행 중

• 해결안 구현 - 검토 - 피드백

• 유지관리자 필요(Django에 한함)

• 완료

기능 아이디어나 Django의 방향에 대한 논의가 Django Forum에서 이루어지는 경우도 있습니다. 이러한 논의에는 비공식 투표가 포함될 수 있으며, Apache에서 고안되어 Python에서도 사용되는 투표 방식을 따릅니다. 이 투표는 +1, +0, -0, -1로 표현됩니다. 대략적으로 각 투표의 의미는 다음과 같습니다.

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

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

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

• -1: “강하게 반대하며, 이 아이디어가 실제로 구현되는 것을 보고 싶지 않습니다.”

이러한 투표는 비공식적이지만 그 결과를 매우 중요하게 받아들입니다. 적절한 투표 기간을 거친 후 명확한 합의가 이루어지면 그 결과를 따릅니다.

Django 프리릴리스 버전 테스트 방법

프리릴리스를 테스트하는 것은 Django에 기여하는 좋은 방법입니다. 초기 테스터들은 최종 릴리스 전에 버그를 발견하는 데 도움을 주어, 모든 사람이 더 원활하게 업그레이드할 수 있도록 합니다.

사전 요구 사항

프리릴리스를 테스트하기 전에, 프로젝트가 Django의 최신 안정 릴리스에서 원활하게 동작하는지 확인하는 것이 중요합니다. 이렇게 해야 회귀 문제를 프리릴리스 탓으로 돌릴 수 있습니다. 최신 버전으로 업데이트하는 방법은 Django를 최신 버전으로 업그레이드하는 방법 가이드를 참고하세요.

프로젝트가 준비되었는지 확인하려면 다음 사항도 수행해야 합니다:

• 릴리스 노트를 읽으세요: 다가오는 버전의 :doc:`/releases/index`를 검토하여 지원 중단된 기능의 업그레이드 경로나 사소한 하위 호환 변경 사항을 확인하세요.

• 지원 중단 경고를 해결하세요: 지원 중단 경고를 활성화한 상태로 테스트를 실행하여 필요한 후속 조치를 파악하세요:

  $ python -Wa manage.py test
  

프로젝트 테스트

``pip``를 사용하여 최신 프리릴리스를 설치할 수 있습니다:

$ python -m pip install --pre Django

설치 후 프로젝트의 테스트 스위트를 실행하세요. 단순히 테스트 통과 여부만 확인하지 말고 다음을 시도해 보세요:

• 의존성 지원 여부를 확인하세요: PyPI에서 Django 버전 분류자를 확인하여 주요 의존성이 새 버전을 지원하는지 파악하세요. 해당 프로젝트들도 초기 버그 보고를 중요하게 여기므로, 지원 여부가 확실하지 않더라도 테스트를 미루지 마세요.

• 성능을 모니터링하세요: test --durations 플래그를 사용하여 테스트를 실행하면 잠재적인 성능 회귀를 식별할 수 있습니다.

• CI에서 테스트를 자동화하세요: 프리릴리스 버전으로 CI(지속적 통합) 파이프라인을 실행하는 것을 고려해 보세요.

• Test manually: While automated tests are great, manually testing your application’s main workflows is an important part of verifying compatibility with a new release.

문제 보고

버그를 발견한 경우, 최종 릴리스 전에 수정될 수 있도록 `Django 이슈 트래커 <https://code.djangoproject.com/>`_를 통해 보고해 주세요. 티켓을 생성할 때 Django 버전 필드를 테스트 중인 프리릴리스의 정확한 버전으로 설정해야 합니다.

회귀 문제를 의심하는 경우, 해당 문제를 유발한 특정 커밋을 보고하면 도움이 됩니다. 방법은 :ref:`bisecting-a-regression`을 참고하세요.

Django Forum`_의 `Pre-releases 카테고리에서 문제를 논의하거나 피드백을 공유할 수도 있습니다.