도움말:이슈 트래커

리브레위키 이슈 트래커에 버그를 제보하려는 사람을 대상으로 한 글입니다. 문의 및 건의는 이곳을 참고해 주세요.

미완성이며, MDN 글을 CC BY SA 2.5 에 따라 번역/수정한 버전입니다.

원 저자는 Jesse Ruderman et al. 입니다.

1 문제를 제보하기 전에

1.1 한 티켓에 한 문제만 적어 주세요

그래야 개발자가 효율적으로 버그를 추적할 수 있습니다.

1.2 버그를 보고하기 전에 확인해야 할 정보

1. 여러 가지 문제가 있다면, 문제 한 가지에 이슈 하나만 만들어 주세요.
2. 버그를 재현할 수 있어야 합니다.
   • 정확한 순서대로 버그를 재현할 수 있다면, 바로 다음으로 넘어갑니다.
   • 버그가 때때로 일어난다면, 추가적인 정보를 제공해야 정보가 유용해집니다.
   • 개발자가 버그를 재현하여 확인할 수 없다면 버그를 리포트하더라도 아무 소용이 없습니다. 안 하는 것이 낫습니다.
3. 미디어위키 기능 제안의 경우 대부분 WONTFIX 로 종결됩니다. 이는 해당 기능이 미디어위키에서 구현되는 것이 더욱 적절하기 때문입니다. 이럴 경우에는 위키미디어 파브리케이터에 기능을 요청합니다. revi를 CC해 주시면 감사합니다.
4. 이제 새 이슈 창으로 이동합니다. 계정이 없다면 별도로 만들어야 합니다.
   • 간략한 요약을 적습니다. 무엇을 적어야 하는지 아래에 있습니다.
   • 프로젝트에 게시판, 미디어위키, 파브리케이터 등 중에서 선택합니다.
   • 버그의 재현 방법, 예상했던 결과와 실제 결과를 적습니다.
   • 특정 브라우저에서만 일어나거나, 특정 OS에서만 일어나는 것 같다면 해당 브라우저 정보도 같이 적습니다.

2 명확한 요약 적기

당신의 문제를 어떻게 요약하시겠습니까? 이 부분은 개발자가 버그를 확인할 때 가장 처음 확인할 수 있는 부분입니다.

좋은 요약은 빠르고 정확하게 당신의 문제점을 개발자에게 인식시켜 줍니다. 요약은 문제점을 적어야지, 당신이 제안하는 해결책을 적어서는 안 됩니다.

• 좋은 예시: "난 어두운 화면이 좋아요!" 이동 요청
• 나쁜 예시: 검색창 오류

• 좋은 예시 2: 러브라이브! 문서의 역사가 깨졌음
• 나쁜 예시 2: 문서 역사 깨짐

3 버그 재현 방법 적기

어떻게 해야 개발자가 개발자 컴퓨터에서 버그를 볼 수 있을까요?

버그를 재현하는 방법을 적는 것은 버그 리포트에서 가장 중요한 요소입니다. 개발자가 본인 컴퓨터에서 버그를 똑같이 재현할 수 있다면, 개발자가 버그를 바로 확인하고 고칠 수 있습니다. 버그가 언제 뜨는지 모른다면, 버그가 고쳐졌는지도 알 수 없겠죠.

버그 리포트에는 무엇이 있어야 할까요?	좋은 예시	나쁜 예시
버그를 항상 보는지, 가끔 보는지, 아니면 한번 보고 말았는지 적습니다.	N/A	N/A
어떤 방법을 취했는지 자세하게 기록합니다.	1. 피자 먹고 싶다의 편집창을 엽니다. 2.{{DISPLAYTITLE:치킨먹고싶다}}를 피자 먹고 싶다의 최상단에 넣습니다.	{{DISPLAYTITLE:치킨먹고싶다}}를 삽입합니다.
방법을 취한 후에, 예상했던 결과와 실제 결과를 요약합니다.	예상했던 결과: 제목란이 치킨먹고싶다로 표시된다 / 실제 결과: 아무 일도 없다	작동을 안 해요

4 추가적인 정보 제공하기

당신의 버그가 특정 OS (iOS, 안드로이드, 데비안, 우분투....)나 특정 브라우저 (토르 브라우저 번들, 구글 크롬 카나리아...)에서만 발생한다면, 그러한 사실을 언급해야 합니다.

5 정확한 프로젝트 찾기

리브레 위키 이슈 트래커에는 여러 가지 프로젝트가 있습니다. 이 중 일반 사용자가 실제로 사용하게 되는 프로젝트는 다음과 같습니다.

프로젝트를 구독자에 추가하지 말아 주세요!

• 게시판: 게시판과 관련된 이슈입니다. IP 차단 요청, 스팸필터 요청 등은 여기로 접수해 주세요.
• 리브레 맵스: 리브레 맵스 관련 이슈입니다.
• 리브레엔진: Project:리브레 엔진
• 미디어위키: 미디어위키의 버그나 확장기능 제안을 다룹니다.
• 소도구: 소도구와 관련된 버그입니다. 개발자가 아닌 운영진도 관리할 수 있는 영역입니다.
• 찾아 바꾸기 봇: 찾아 바꾸기 활동을 요청하는 곳입니다.
• 파브리케이터: 파브리케이터 자체에 대한 문제를 다룹니다.
• OTRS: OTRS와 관련된 이슈입니다. 운영진 변동에 따른 새 계정 요청은 여기로 접수해 주세요.

다음 프로젝트는 특정 상황에서만 제한적으로 사용됩니다. 일반 사용자는 사용하지 않습니다.

• 보안: 보안과 관련된 이슈 (XSS, CSRF, 비공개 게시글이 보인다던가 하는 문제)
• 합의 필요: 위키방에 올려 사용자의 토론이 필요한 문제
• ACL-(*): 파브리케이터 접근 권한을 다루는 프로젝트.
• 회계: 금전 관련 이슈.
• 개발자: 개발자 리스트 겸 ACL 프로젝트입니다.
• Ops: 서버 운영.

6 버그 보고하기

파브리케이터 대문

선택창.

새 버그 자신이 선택할 수 없는 게 보이더라도 놀라지 말자.

프로젝트들

1. 파브리케이터에 들어갑니다.
2. 선택창에서 Bug Reports 옵션를 선택합니다.
3. Title에 버그의 제목을 간결하게 적습니다.
4. 프로젝트에서 적절한 프로젝트를 선택합니다. 여러 개 선택할 수 있습니다.
5. Description에 설명을 적습니다. (이 부분은 추후에 개발자와 같은 다른 사용자가 편집할 수 있음을 명심하세요.)
6. 다 됐다면, Create Task를 클릭하면 이슈가 생성됩니다.

상태와 우선순위

버그의 상태는 크게 Open과 Closed 상태로 나눌 수 있습니다. Open 상태는 버그가 열려 있으며, 무언가 조치가 필요한 상태임을 나타냅니다. Closed는 버그가 종결되었음을 의미합니다. Closed는 5개의 세부 항목으로 나눌 수 있습니다.

• • Resolved: 버그가 해결되었습니다. 더이상의 작업이 요구되지 않습니다.
  • Invalid: 실제로는 버그가 아닌 항목이거나, 개발자가 버그를 재현할 수 없어 문제를 해결할 수 없는 경우 사용합니다.
  • Declined: 개발자가 문제의 해결을 거절한 항목입니다. 개발팀 정책과 상반되는 요청 등에 사용됩니다.
  • Duplicate: 중복 항목입니다. 이미 해당 문제가 보고된 상황에서 사용자가 기존의 항목을 인지하지 못하고 새 항목을 작성하였을 때 사용됩니다.
  • Spite: 스팸, 장난성 항목 등에 사용되는 항목입니다.

일반 사용자는 상태값을 수정할 수 없으며, 개발자만이 편집할 수 있습니다.

버그의 우선순위는 해당 버그의 중요성을 결정합니다. 가장 높은 Unbreak now! 부터 Wishlist까지 6가지의 값이 존재합니다.

• • Unbreak now!: 긴급 상황으로써, 하던 일 다 옆에 치우고 이 문제를 해결하는 데 골몰해야 합니다.
  • Needs Triage: 분류가 필요합니다. 일반 사용자가 생성하는 버그는 이 값으로만 생성할 수 있으며, 개발자가 검토 후 우선순위를 결정하게 됩니다.
  • High: 상당히 중요한 문제로써, 되도록 빠르게 처리해야 합니다.
  • Normal: 일반적인 버그는 대부분 이 분류에 분류됩니다.
  • Low: 중요도가 높지 않은 문제로써 천천히 해결해도 위키에 큰 문제가 발생하지 않을 것으로 예측됩니다.
  • Wishlist: 기능 제안 등의 제안사항은 이 항목에 분류됩니다.

우선순위는 개발자와 개발자로부터 우선순위값의 조정을 허가받은 사용자만이 편집할 수 있습니다.