이슈 추적

Wagtail의 GitHub 이슈 트래커를 통해 버그 리포트, 기능 요청, 풀 리퀘스트를 환영합니다.

이슈

이슈는 항상 잘 정의된 완료 상태를 가진 특정 작업에 해당해야 합니다: 버그 수정, 새 기능 추가, 문서 업데이트 또는 코드 정리. 최종 결과가 즉시 명확하지 않은 개방형 이슈(“번역을 수행하는 방법 고안” 또는 “리치 텍스트 필드에 더 많은 기능 추가”)는 GitHub 토론에 더 적합합니다. 이를 통해 이슈를 진행하고 토론에서 생성된 별도의 이슈를 통해 완료 시점을 식별하는 명확한 방법에 대한 피드백을 받을 수 있습니다.

지원 문의나 기타 질문(“X를 어떻게 하나요?” - “X를 수행하는 방법 구현” 또는 “X 수행 방법 문서화”는 유효한 이슈가 될 수 있음)에 이슈를 사용하지 마세요. 이러한 질문은 대신 Stack Overflow에 질문해야 합니다. Stack Overflow의 질의응답 형식에 맞지 않는 토론은 다른 Wagtail 커뮤니티 지원 옵션을 참조하세요.

티켓이 열리자마자 - 가급적 하루 안에 - 핵심 팀 구성원이 초기 분류를 수행합니다. 유효하지 않은 경우 닫거나 관련 레이블로 업데이트합니다. 버그가 열리면 자동으로 type:Bug 및 status:Unconfirmed 레이블이 할당되며, 버그가 확인되면 미확인 상태를 제거할 수 있습니다. 팀 구성원은 이 이슈의 우선순위를 안내하기 위해 릴리스 마일스톤을 추가할 수도 있습니다. 누구나 status:Unconfirmed 버그를 재현하고 필요한 경우 추가 재현 단계를 통해 유효한 버그인지 여부에 대해 댓글을 달아 Wagtail을 도울 수 있습니다.

티켓이 마땅한 것보다 낮은 우선순위를 받았다고 생각하더라도 낙심하지 마세요. 이 결정은 영구적이지 않습니다. 모든 피드백을 고려하고 적절한 경우 티켓을 재할당하거나 다시 열 것입니다. (다른 한편으로, 이는 분류를 수행하는 핵심 팀 구성원이 대담한 일방적인 결정을 자유롭게 내릴 수 있음을 의미합니다. 먼저 합의를 구할 필요가 없습니다. 잘못된 판단을 내리면 나중에 언제든지 뒤집을 수 있습니다.)

할당될 수 있는 가능한 마일스톤은 다음과 같습니다.

  • invalid (닫힘): 이 이슈는 수행할 특정 작업을 식별하지 않거나, 우리가 수행하려는 작업이 아닙니다. 예를 들어 - 설계된 대로 작동하는 것에 대한 버그 보고서 또는 적극적으로 해로운 기능에 대한 기능 요청.

  • real-soon-now: 현재 핵심 팀에 할당된 리소스는 없지만, 이것이 문제점임을 알고 있으며 다음에 새로운 작업을 선택할 기회가 있을 때마다 우선순위가 정해질 것입니다. 실제로 그런 자유로운 선택은 자주 일어나지 않습니다. 매일 작업하는 것을 결정하는 데 많은 압력이 있습니다. 따라서 이것이 필요한 기능이나 수정이라면 핵심 팀이 처리하기를 기다리기보다는 직접 작업하고 풀 리퀘스트를 기여하는 것이 좋습니다!

  • 특정 버전 번호 (예: 1.6): 이 버전에서 수정해야 할 만큼 중요한 이슈입니다. 주어진 버전에서 이슈 작업을 위한 리소스가 할당되었거나 계획이 있습니다.

  • 마일스톤 없음: status:Unconfirmed 레이블이 제거되면(합법적인 버그 보고서 또는 유용한 기능 요청으로 확인될 때) 이슈가 유효한 것으로 수락되지만 (핵심 팀의 의견으로는) 작업 우선순위로 간주되지는 않습니다. 예를 들어 - 단지 외관상의 버그이거나, 있으면 좋지만 그다지 필수적이지는 않은 기능. 할당된 리소스가 없습니다. 자유롭게 맡아주세요!

경우에 따라 핵심 팀이 이슈를 마일스톤으로 분류하는 데 더 오래 걸릴 수 있습니다. 예를 들어:

  • 버그의 존재를 확인하는 데 사소하지 않은 작업이 필요할 수 있습니다. 이 경우, 버그를 재현할 수 있는지 여부에 관계없이 다른 기여자의 피드백과 추가 세부 정보가 특히 환영됩니다.

  • 제안이 좋은 아이디어인지 아닌지를 결정하기 위해 추가 논의가 필요할 수 있습니다. 그렇다면 “design decision needed”로 태그가 지정됩니다.

이슈가 이 상태로 장기간 유지되지 않도록 노력할 것입니다. “design decision needed” 태그가 붙은 이슈와 PR은 정기적으로 재검토되고 최소 두 명의 핵심 기여자와 논의될 것입니다. 주간 핵심 팀 회의의 일환으로 각 티켓을 릴리스 주기(= 6주)당 최소 한 번 검토하는 것을 목표로 합니다.

풀 리퀘스트

이슈와 마찬가지로, 핵심 팀은 풀 리퀘스트가 열리자마자, 보통 하루 안에 분류할 것입니다. 변경 사항이 유효하지 않거나 특히 논란의 여지가 있는 경우(이 경우 닫히거나 “design decision needed”로 표시됨)를 제외하고는, 일반적으로 다음 해당 버전(새로운 기능의 경우 다음 마이너 릴리스, 버그 수정의 경우 다음 패치 릴리스)으로 분류되고 ‘Needs review’로 표시됩니다.

  • 핵심 및 비핵심 기여자를 포함한 모든 기여자는 풀 리퀘스트에 대한 피드백을 제공하도록 초대됩니다.

  • 핵심 팀 구성원은 검토를 위해 풀 리퀘스트에 자신을 할당하도록 초대됩니다.

  • 풀 리퀘스트를 분류하는 방법에 대한 더 구체적인 세부 정보는 PR 분류 위키 페이지에서 찾을 수 있습니다.

그 후 (이상적으로는 1~2주 이내, 그러나 더 큰 제출물의 경우 더 길어질 수 있음) 핵심 팀 구성원은 병합할 준비가 되면 병합하거나 추가 작업이 필요하다고 태그를 지정합니다(‘needs work’ / ‘needs tests’ / ‘needs docs’). 추가 작업이 필요한 풀 리퀘스트는 이슈와 동일한 방식으로 처리되고 우선순위가 지정됩니다. 원래 커미터인지 여부에 관계없이 누구나 백로그에서 하나를 선택하여 작업할 수 있습니다.

풀 리퀘스트의 리베이스 / 스쿼시는 환영하지만 필수는 아닙니다. 그렇게 할 때, 검토가 필요한 커밋을 이전 커밋으로 스쿼시하지 말고 변경 순서를 유지해야 합니다. 이전 커밋의 실수를 수정하려면 git commit --fixup 을 사용하여 최종 병합이 git rebase -i --autosquash 로 수행될 수 있도록 하세요.

Wagtail에서 작업하는 핵심 팀 구성원은 프로젝트의 자체 포크로 동일한 프로세스를 거쳐야 합니다.

릴리스 일정

2개월마다 새 버전을 출시하는 것을 목표로 합니다. 이 일정을 지키기 위해, 현재 릴리스를 지연시키는 대신 필요한 경우 이슈와 PR을 향후 릴리스로 ‘넘기는’ 경향이 있습니다. 이러한 이유로 특정 릴리스 마일스톤 아래에 이슈가 태그된 것이 해당 릴리스에서 기능이 실제로 제공될 것이라는 보증으로 받아들여져서는 안 됩니다.