이슈 추적기 사용하기¶
issue tracker는 코드베이스 및 풀 리퀘스트와 함께 GitHub에서 호스팅됩니다.
참고
이슈 추적기를 GitHub로 이전하기 전에는 Python이 전용 Roundup 인스턴스를 이슈 추적기로 사용했습니다. 해당 old bug tracker는 bugs.python.org 도메인에서 호스팅되었습니다(때로 bpo 또는 BPO로 줄여 불렸습니다). 역사적 기록을 위해 해당 도메인에서 읽기 전용 버전을 이용할 수 있습니다. 모든 bpo 데이터는 GitHub의 현재 이슈 추적기로 이전되었습니다. 이전 이슈는 여전히 bpo-NNN 형식으로 참조되며, bpo-12345는 https://bugs.python.org/issue12345를 가리킵니다.
이슈 보고하기¶
Python에서 버그를 발견했다고 생각한다면 issue tracker에 보고할 수 있습니다. 문서 버그도 이곳에 보고할 수 있습니다.
이 개발자 가이드에 관한 이슈를 제출하려면 대신 devguide repository에 제출하십시오.
버그가 이미 존재하는지 확인하기¶
이슈 보고서를 제출하기 전 첫 단계는 해당 문제가 이미 보고되었는지 확인하는 것입니다. 문제가 기존 이슈인지 확인하면 다음과 같은 이점이 있습니다:
문제가 이미 해결되었거나 다음 릴리스에서 수정되었는지 확인하는 데 도움이 됩니다.
본인과 개발자의 시간을 절약합니다.
문제를 수정하기 위해 무엇을 해야 하는지 파악하는 데 도움이 됩니다.
이슈 재현 방법과 같은 추가 정보가 필요한지 판단하는 데 도움이 됩니다.
이슈가 이미 존재하는지 확인하려면 이슈 페이지의 버그 목록 위에 있는 검색 상자를 사용하여 버그 데이터베이스를 검색하십시오. 자세한 내용은 이슈 검색를 참조하십시오.
새 이슈 만들기¶
보고하려는 문제가 아직 issue tracker에 없다면 버그 목록 위 검색 상자의 오른쪽에 있는 녹색 New issue 버튼을 사용하여 보고할 수 있습니다. 아직 GitHub에 로그인하지 않았다면 지금 로그인하라는 메시지가 표시됩니다.
먼저 보고하려는 문제의 종류를 선택해야 합니다. 선택할 수 있는 항목의 예는 다음과 같습니다:
Bug report: 기존 기능이 예상대로 작동하지 않습니다.
Documentation: 문서가 누락되었거나 잘못되었거나 오해의 소지가 있습니다.
Feature or enhancement: Python의 새로운 기능을 제안합니다.
Report a security vulnerability: 보안 취약점을 비공개로 보고합니다.
선택한 항목에 따라 전용 양식 템플릿이 표시됩니다. 특히 버튼 중 하나를 누르면 실제로 Python Discourse (discuss.python.org)로 이동하며, 이곳에서는 Python과 관련된 많은 토론이 이루어집니다.
제출 양식에는 작성해야 하는 필드가 두 개뿐입니다:
Title 필드에는 문제를 매우 짧게 설명하십시오. 열 단어 미만이 좋습니다. GitHub 레이블을 사용하므로
[feature]같은 “레이블”은 포함하지 마십시오.Write 필드에서는 해당 필드에 제공된 템플릿의 안내를 활용하여 문제를 자세히 설명하십시오. 예상한 결과, 실제로 발생한 결과, 문제를 재현하는 방법을 반드시 포함하십시오. 확장 모듈이 관련되었는지와 사용한 하드웨어 및 소프트웨어 플랫폼도 반드시 포함하십시오(적절한 경우 버전 정보도 포함합니다). 특히 어떤 버전의 Python을 사용했는지 포함하십시오.
이슈에 주의를 기울여야 한다고 생각하는 사람이 있다면 댓글에서 @username으로 태그할 수 있습니다. 특정 영역에서 태그되거나 담당자로 지정되기를 원하는 사람이 누구인지 알아보려면 전문가 색인를 참조하십시오.
Assignees, Labels, Projects 같은 추가 필드도 여러 개 있습니다. 이러한 필드는 트리아지 담당자와 코어 팀 구성원이 작성하며 이슈 트리아지 페이지에서 설명합니다. Python 사용자로서 이슈를 보고할 때는 이러한 필드를 신경 쓰지 않아도 됩니다.
이슈 다루기¶
이 절에서는 이슈 검색, 댓글 작성, 이슈 팔로우 같은 이슈 추적기의 일반적인 작업을 다룹니다.
이슈 검색¶
GitHub search syntax를 사용하거나 검색 쿼리를 생성해 주는 대화형 advanced search 양식을 사용하십시오.
이슈 목록 위의 Labels 드롭다운이나 label:name 검색 한정자를 사용하여 레이블별로 필터링하면 결과 범위를 좁힐 수도 있습니다. CPython 저장소에서 사용하는 레이블의 개요는 GitHub 레이블를 참조하십시오.
이슈와 댓글 서식 지정하기¶
훌륭한 GitHub에서 글을 작성하고 서식을 지정하는 방법에 관한 초보자용 안내서가 있습니다. 강력히 권장합니다.
여기서 바로 알려 드릴 수 있는 유용한 팁은 긴 로그를 댓글로 붙여 넣고 싶다면 파일을 대신 첨부하는 것입니다. 그래도 계속 댓글에 붙여 넣으려면, 가독성을 높이기 위해 <details></details>를 사용하여 collapsed section으로 감싸십시오.:
<details>
<summary>This is the summary text, click me to expand</summary>
Here goes the long, long text.
It will be collapsed by default!
</details>
파일 첨부하기¶
파일을 댓글 필드로 끌어다 놓고 업로드가 끝날 때까지 기다리면 GitHub가 댓글 텍스트에 해당 파일의 링크를 자동으로 삽입합니다.
링크 추가하기¶
댓글에서 다음 약어를 사용하여 링크를 생성할 수 있습니다.
GH-NNN: 다른 이슈나 PR에 연결합니다.PEP-NNN: 특정 PEP에 연결합니다.BPO-NNN: bugs.python.org 이슈에 연결합니다.
GitHub에서 지원하는 자동 링크 목록도 참조하십시오.
저장소의 파일에 연결하려면 “y” 누르기를 통해 파일의 특정 리비전에 대한 영구 링크를 얻을 수 있습니다.
이슈 팔로우하기¶
이슈를 구독하려면 사이드바에서 🔔 Subscribe 버튼을 클릭하십시오. 다른 사람을 이슈에 구독시키려면 댓글에서 @username 형식으로 해당 사용자를 태그하십시오. 다른 사람이 자신을 태그했지만 이 이슈가 자신과 관련이 없다고 판단했다면 사이드바에서 🔕 Unsubscribe 버튼을 클릭하십시오. 자신이 만들거나 댓글을 작성한 이슈는 자동으로 구독하게 된다는 점에 유의하십시오.
의존성과 중복 추적¶
이슈 간 관계 만들기 기능으로 의존성을 추적할 수 있으며, 메타 이슈의 경우 하위 이슈 추가하기 기능으로 관련된 다른 이슈에 연결할 수 있습니다.
댓글에 Duplicate of #NNN를 작성하여 이슈와 PR을 중복으로 표시하기 기능을 사용할 수 있습니다.
마네킹 계정¶
작성자나 댓글 작성자가 코어 팀 구성원이 아니었던 bugs.python.org(BPO)의 이전 이슈를 GitHub로 이전할 때는 해당 사용자의 GitHub 계정에 직접 연결하지 않기로 했습니다. GitHub의 python 조직에 속하지 않은 사용자는 자동 가져오기로 생성된 댓글이 자신의 이름으로 표시되는 것을 원하지 않을 수 있습니다. 또한 애초에 BPO에서 GitHub 계정을 연결하지 않은 사용자도 있었으므로 계정이 있더라도 연결할 수 없습니다.
이러한 경우에는 이슈에서 이루어진 대화를 쉽게 따라갈 수 있도록 “마네킹” 계정이 표시됩니다. 사용자가 BPO 프로필에 GitHub 계정 이름을 공개한 경우에는 해당 이름을 사용합니다. 그렇지 않으면 기존 BPO 사용자 이름을 대신 사용합니다.
해결 결과에 대한 이견¶
사람인 만큼 때때로 의견이 다를 수 있습니다. 무엇보다도 해결 결과에 세심한 배려와 숙고, 자원봉사자의 시간이 투입되었다는 점을 존중하십시오. 기여자들은 매우 다양한 문화적·언어적 배경을 지니고 있다는 점을 명심하십시오. 문화와 언어를 넘나드는 소통을 참고하십시오.
이를 염두에 두고 이슈의 해결 결과와 관련하여 작성된 모든 댓글을 충분한 시간을 들여 검토하십시오. 다시 생각해 보면 해결 과정이 처음 생각했던 것보다 더 합리적으로 보일 수 있습니다.
그래도 여전히 해결이 잘못되었다고 생각한다면 Core Development Discourse category에서 신중하게 질문하십시오. 코어 개발자들 사이에서 합의가 이루어진 후에도 계속 논쟁하거나 무례하게 대응해서는 다른 사람의 생각을 바꾸기 어렵습니다.
다시 한번 말씀드리지만, 코어 개발자가 닫은 이슈는 이미 신중하게 검토된 것입니다. 닫힌 이슈를 다시 열지 마십시오. 이슈는 complete 또는 not planned 중 하나를 사유로 지정하여 닫을 수 있습니다.