이슈 트리아지

이 페이지는 rust-lang/rust 저장소에 관한 것입니다. rust-lang GitHub 조직 산하의 다른 저장소는 다른 절차를 가지고 있을 가능성이 있습니다.

추적 이슈(C-tracking-issue 레이블이 붙은 이슈)는 이 절차에 해당하지 않으며 다르게 처리됩니다.

동기

rust-lang/rust 저장소에는 수천 개의 이슈가 있으며, 수백 명이 작업하고 있습니다. 모든 사람이 이슈를 확인하고 해결하는 것은 불가능합니다. 트리아지의 목표는 다음과 같습니다.

• 발견 가능성을 향상시킵니다.
  • 이슈가 어느 팀과 관련이 있을지 분류합니다.
  • 회귀가 적절히 태그되고 추적되도록 합니다.
  • 이슈를 관련된 사람(특히 관련 팀)과 연결합니다.
• 이슈 성격의 1차 대략 분류입니다.
  • 이 이슈가 버그인지, 논의인지, 아니면 사용자 측 문제인지 판단합니다.
• 이슈가 충분히 조치 가능한지 파악합니다.
  • 보고서에 재현 단계, 재현 코드, 또는 빌드/실행 환경 정보 등 추가 정보가 필요한지 확인합니다.
  • 재현 코드에 최소화가 필요한지 확인합니다.
• 적절한 레이블을 적용하여 기여자가 이슈를 필터링하기 쉽게 만듭니다.

실제로는 모든 이슈가 신속히 해결되고 적합한 사람에게 발견되는 것은 비현실적입니다. 레이블을 적용함으로써 이슈 트래커를 향후 참조에 더 검색하기 쉽게 만들어, 나중에 사람들이 관련 이슈나 자신이 작업하고 싶은 이슈를 더 쉽게 찾을 수 있도록 합니다.

트리아지는 rust-lang/rust에 대한 쓰기 권한이 있든 없든 누구나 할 수 있습니다. 트리아지 작업은 병렬화가 매우 용이하고 시작하기 쉬우므로, 모두가 참여해 도움을 주기를 권장합니다.

rust-lang/rust에 대한 쓰기 권한이 필요한 작업의 예는 다음과 같습니다.

• @rustbot transfer를 사용하여 이슈를 rust-lang GitHub 조직 산하의 다른 저장소로 이전합니다.
• 이슈를 닫습니다.
• @rustbot을 사용하여 쓰기 권한이 필요한 특정 레이블을 적용합니다(아래 “레이블 적용 및 제거” 섹션 참조).

쓰기 권한이 없더라도 이러한 조치가 필요하다고 판단되면, t-release/triage Zulip 채널에 새 토픽을 열거나, t-release/triage 채널의 기존 토픽에 해당 이슈를 링크하는 댓글을 추가하면 됩니다.

초기 트리아지

이슈가 열리면 보통 needs-triage 레이블이 자동으로 부여됩니다. 이는 트리아지되지 않은 이슈를 쉽게 발견하고 필터링할 수 있도록 하여, 새 이슈가 초기 트리아지 과정(아래에 설명)을 거치도록 하기 위한 것입니다. needs-triage는 초기 체크포인트입니다. 이슈가 이 레이블에서 벗어나는 데 필요한 노력은 적어야 합니다.

초기 트리아지를 수행하고 needs-triage 레이블을 제거하려면 다음 조건들이 충족/고려되어야 합니다. 이 조건들이 항상 모두 고려되지 않아도 괜찮습니다. 이 목록은 완전한 것이 아니며, 엄격한 체크리스트가 아니라 지침으로 다루십시오:

• 이슈는 말이 되어야 합니다. 즉, 문제를 제시해야 합니다.
  • 예를 들어, 이슈가 Rust 전반에 대한 질문이라면 해당 이슈는 닫히고 사용자는 URLO로 안내되어야 합니다. 물론 질문에 답변해도 되지만, 다음번에는 URLO로 가야 한다는 점을 반드시 언급하십시오.
• 이 이슈가 이전에 보고된 이슈의 중복인지 확인하십시오.
  • 중복이 확실하다면, 이 이슈를 이전 이슈의 중복으로 처리하여 닫으십시오. 이전 이슈의 백링크에서 이 사실이 명확히 드러나도록 하거나, 중복 이슈에 명시적으로 링크하십시오.
  • 확신이 서지 않는다면, 다른 이슈가 중복이거나 유사하거나 관련이 있을 가능성을 나타내는 댓글만 남겨도 됩니다.
• 적절한 라벨을 추가하십시오 (Labels).
  • 특히 팀 라벨(T-*)과 이슈 카테고리 라벨(C-*)이 가장 중요합니다. 팀원들은 보통 이를 기준으로 삼아 (예: 트리아지 회의 중) 자신의 팀과 관련된 것을 걸러내기 때문입니다.
• 이슈에 재현 방법이 없지만 필요한 경우(의심스러우면 필요한 것입니다), 재현 방법을 요청하고 S-needs-repro 레이블을 추가하십시오.
• 이슈에 정보가 부족한 경우(예: 시스템 정보, 정확한 호출 방식), 문제를 재현하는 데 중요한 정보를 제공하도록 보고자에게 요청하십시오. S-needs-info 레이블을 추가하십시오.
• 이슈 트래커는 일부 종류의 기능 요청에는 적절하지 않은 장소입니다. 작성자를 적절한 채널로 안내하십시오:
  • 표준 라이브러리 API 요청은 libs 프로세스를 따라야 합니다.
  • 언어 변경 사항은 IRLO 또는 T-lang Zulip 채널(t-lang)로 안내되어야 합니다.
• 이슈가 회귀 지점을 이분 탐색(bisect)함으로써 도움이 될 수 있다면(의심스러우면 도움이 될 수 있는 것입니다), E-needs-bisection을 추가하거나 직접 이분 탐색을 수행하십시오. 유용한 이분 탐색 도구로 cargo-bisect-rustc가 있습니다.
  • 이분 탐색 결과가 있고 그 결과가 설득력이 있다면, S-has-bisection을 추가하십시오.
• 보고된 예제가 크거나 복잡한 경우(예: 코드가 많거나, 외부 의존성이 많거나, 실제 문제를 흐리는 무관한 경고나 오류가 있는 경우), 예제를 최소화할 필요가 있음을 나타내기 위해 E-needs-mcve를 추가하십시오.
  • 최소화되고 완전하며 검증 가능한 예제(MCVE)가 있다면, 이슈에 S-has-mcve 태그를 붙이십시오. 최소화가 유효한지 다시 확인하십시오. 예를 들어 MCVE가 원래 문제에 대한 것이며 다른 문제로 변질되지 않았는지 확인하십시오.
• 이 이슈는 회귀입니까? 그렇다면 regression-untriaged 레이블을 적용하거나(또는 정확히 어떤 회귀인지 파악하십시오). 일반적으로, 예전에는 작동했지만 더 이상 작동하지 않는 경우 그 이슈는 회귀로 간주됩니다.
• 이 이슈와 관련이 있는 사람을 알고 있다면, 그들에게 핑을 보내십시오.
  • 예를 들어, ThatPerson이 최근 해당 기능에 대해 많은 작업을 해왔다면 cc @ThatPerson이라고 작성하십시오.
• 이 이슈는 어떤 기능을 사용합니까? 해당하는 F-* 레이블을 추가하십시오. 예: F-const_trait_impl.
• 이 이슈는 기능을 사용하지 않으면서도 nightly를 필요로 합니까? requires-nightly를 추가하십시오.
• 이 이슈는 내부 기능이 필요합니까? requires-internal-features를 추가하십시오.

레이블 적용 및 제거

rust-lang/rust에 대한 쓰기 권한이 없는 사용자는 우회 방법으로 @rustbot을 사용하여 triagebot.toml 설정에서 허용된 레이블을 추가하거나 제거할 수 있습니다.

쓰기 권한이 있는 사용자는 이슈를 구독 중인 모든 사람에게 불필요하게 알림이 전송되지 않도록 레이블을 직접 변경해야 합니다.

예를 들면:

@rustbot label +T-compiler +C-bug +A-linkage +O-macos -needs-triage

모든 레이블 목록을 보려면 이슈 트래커의 검색창 옆에 있는 “labels” 페이지를 확인하십시오.

일부 레이블은 rust-lang/rust에 쓰기 권한이 있는 사용자만 적용할 수 있다는 점에 유의하십시오. 쓰기 권한이 없는 사용자가 사용할 수 있는 레이블을 확인하려면 triagebot.toml의 [relabel] 섹션 아래에 있는 allow-unauthenticated 목록을 참조하십시오.

Relnotes 트리아지

relnotes-tracking-issue로 레이블이 지정된 이슈의 경우, 릴리스 노트 텍스트가 정리될 때까지 needs-triage 태그를 제거해서는 안 됩니다.

레이블

이슈에 적용할 수 있는 다양한 레이블이 있습니다. 트리아지에 사용하는 레이블 집합은 필요에 따라 항상 변화하며, 저희는 이 목록을 최신 상태로 유지하고자 노력합니다. 레이블은 팀원들이 필요하다고 판단할 때 수동으로 추가합니다.

• needs-triage: 이슈가 새로 생성되어 초기 트리아지가 필요함을 나타냅니다.
• T-*: 이 이슈와 관련된 팀 또는 팀들을 지정합니다. 예를 들어 T-compiler, T-types 또는 T-libs입니다. 자세한 내용은 팀 예시를 참조하십시오.
• WG-*: 이 이슈와 관련된 워킹 그룹을 지정합니다. 예: WG-debugging.
• PG-*: 이 이슈와 관련된 프로젝트 그룹을 지정합니다. 예: PG-exploit-mitigations.
• C-*: 레이블의 범주를 지정합니다. 예를 들어 버그, 추적 이슈 또는 논의입니다.
  • C-optimization: 놓친 컴파일러 최적화를 위한 것입니다.
  • C-defective-hardware: 저희가 통제할 수 없는 하드웨어 버그를 위한 것입니다.
  • C-gub: 문제가 사용자 오류(예: 정의되지 않은 동작)로 인한 경우입니다.
  • C-discussion: 버그는 아니지만 논의할 가치가 있는 경우입니다.
  • C-external-bug: 저희에게 영향을 미치지만 직접 통제할 수는 없는 소프트웨어 버그로, 저희 쪽에서 계속 추적할 가치가 있는 경우입니다.
• O-*: 타겟별 이슈의 경우, 컴파일 타겟¹ 또는 컴파일 타겟 계열(가장 주목할 만하게는 플랫폼, 즉 아키텍처나 운영체제)을 지정합니다. 예를 들어 O-macos, O-aarch64, O-windows, O-windows-msvc입니다.
  • 가능한 한 가장 구체적인 대상 카테고리를 지정합니다. 예를 들어, 어떤 이슈가 *-windows-gnu에는 영향을 미치지만 *-windows-msvc에는 영향을 미치지 않는다면, 일반적인 O-windows 대신 O-windows-gnu를 사용하는 것이 좋습니다.
• A-*: 이슈가 관련된 영역을 나타내며, 예를 들어 A-linkage, A-patterns 또는 A-diagnostics 등이 있습니다. 이는 이슈를 필터링하는 데 특히 유용합니다.
  • A-diagnostics: 진단 이슈 템플릿으로 생성된 이슈는 C-bug가 아니라 A-diagnostics만 가집니다.
• B-*: 차단 요소(blocker)인 이슈입니다.
• D-*: 진단 이슈를 위한 레이블입니다.
  • D-diagnostic-infra: 이 이슈는 진단 인프라 자체에 관한 것입니다.
• L-*: 이슈가 특정 린트와 관련될 때 사용합니다.
  • L-false-positive는 린트가 발동해서는 안 되는 경우에 발동했을 때 사용합니다.
  • L-false-negative는 린트가 발동해야 하는 경우를 놓쳤을 때 사용합니다.
• F-*: 이슈가 특정한(대개 불안정하며 대개 언어) 기능과 관련될 때 사용합니다.
• -Z*: 이슈가 특정 불안정 -Z 컴파일러 플래그와 관련될 때 사용합니다.
• requires-nightly: 이 이슈는 nightly 채널 컴파일러에만 영향을 미치며, beta 또는 stable 채널 컴파일러에는 영향을 미치지 않습니다.
• requires-internal-features: 이 이슈는 내부 기능을 필요로 합니다. 이는 흔히 해당 이슈가 컴파일러 MCP 620에 따라 닫혀야 함을 의미합니다.
• regression-*: 회귀 문제를 추적하는 추적 이슈를 위한 레이블입니다.
  • regression-untriaged: 회귀의 성격과 종류가 불분명하며, 추가적인 회귀 트리아지가 필요함을 나타냅니다.
  • regression-from-stable-to-stable: 이전 stable 릴리스에서 회귀한 것으로, 이미 최신 stable 릴리스나 그 이전 stable 릴리스에까지 도달한 것입니다.
  • regression-from-stable-to-{beta,nightly}: stable 릴리스에서 beta 또는 nightly 채널로 회귀한 것입니다.
• I-*: 이슈의 성격²에 관한 다양한 레이블입니다.
  • I-ICE: 내부 컴파일러 오류입니다.
  • I-prioritize: 필요한 경우 긴급성을 나타내는 우선순위 P-*를 부여하기 위해 T-compiler/ops가 해당 이슈를 추가로 트리아지해야 함을 나타냅니다.
  • I-heavy: 무거운 코드(바이너리 크기)입니다.
  • I-slow: 느린 런타임 성능입니다.
  • I-hang: 컴파일이 오랜 시간이 지나도 완료되지 않는 경우입니다.
  • I-crash: 컴파일러 또는 생성된 코드가 SIGSEGV나 접근 위반(access violation)처럼, ICE로는 드러나지 않는 방식으로 충돌하는 경우입니다.
  • I-unsound: 라이브러리, 컴파일러, 타입 시스템 또는 언어의 불건전성(unsoundness)입니다.
  • I-compilemem: 컴파일 중 과도한 메모리 사용입니다.
  • I-compiletime: 느린 컴파일 시간입니다.
  • I-{team}-nominated: 이슈가 {team}의 논의를 위해 지명되었음을 나타냅니다. 예: I-compiler-nominated.
  • I-lang-easy-decision: T-lang이 내려야 할 결정이 (레이블을 적용하는 사람의 판단으로) 쉽거나 형식적일 것으로 추정됩니다. 이 레이블은 I-lang-nominated를 의미하지 않는다는 점에 유의하십시오. 레이블을 적용하는 사람이 해당 이슈를 T-lang 논의에 상정하고자 한다면, 상정 레이블을 동시에 적용해야 합니다.
• P-*: 우선순위 레이블입니다. 컴파일러 우선순위 지정 절차를 사용하여 적용됩니다.
• E-*: 참여 요청입니다³, 예를 들어 이슈를 최소화하기 위한 것입니다.
  • E-mentor: 이슈를 도와줄 멘토가 있음을 나타내며, 이는 좋은 첫 이슈가 됩니다. 의도된 멘토가 실제로 멘토링할 의사와 시간이 있는지 확인하십시오.
  • E-needs-mcve: 이 이슈에는 재현 사례가 있지만 최소화되지 않았습니다. 최소화되어야 합니다.
  • E-needs-bisection: 이 이슈는 예를 들어 cargo-bisect-rustc를 사용한 이분 탐색이 필요합니다.
  • E-needs-investigation: 이 이슈는 근본 원인과 성격을 파악하기 위해 추가 조사가 필요합니다.
  • E-needs-design: 이 이슈는 상당한 설계 작업(탐색, 프로토타이핑, 논의 등)이 필요합니다.
  • E-needs-test: 이 이슈는 수정되었지만 테스트가 추가되지 않았습니다. 누군가 테스트를 추가하면 종료할 수 있습니다.
  • E-{easy,medium,hard}: 누군가 이 이슈를 수정하기가 얼마나 어려운지 추정했습니다. 이는 좋은 첫 이슈를 찾는 데 도움이 될 수 있지만, 부정확할 수밖에 없습니다.
• S-*: 이슈의 상태를 나타내며, 예를 들어 S-needs-repro 또는 S-needs-info입니다.
  • S-needs-info: 이슈 제보자로부터 더 많은 정보가 필요합니다.
  • S-needs-repro: 재현 방법(코드 샘플, 재현 단계 등)이 필요합니다.
  • S-bug-has-test: 이슈에 rust-lang/rust의 tests/crashes 테스트 스위트나 다른 곳에 알려진 버그 테스트가 있습니다.
  • S-has-bisection: 이분 탐색이 수행되었고 그 결과가 설득력이 있습니다.
  • S-waiting-on-LLVM: 업스트림 LLVM 풀 리퀘스트나 수정을 기다리는 중입니다.
  • S-tracking-forever: 추적 이슈를 종료할 의도가 전혀 없습니다.
• beta-nominated: [beta로 백포트](backported to beta)하도록 지명된 변경 사항을 추적합니다.
• beta-accepted: [beta로 백포트](backported to beta)하도록 승인된 변경 사항을 추적합니다. 백포트는 보통 T-release가 처리합니다.
• stable-nominated: 포인트 릴리스를 예상하여 [stable로 백포트](backported to stable)하도록 지명된 변경 사항을 추적합니다.
• stable-accepted: [stable로 백포트](backported to stable)하도록 승인된 변경 사항을 추적합니다. 백포트는 보통 T-release가 처리합니다.
• relnotes: 다음 릴리스의 릴리스 노트에 문서화하도록 제안된 변경 사항입니다
  • 이는 triagebot이 새로운 relnotes 이슈를 생성하게 만듭니다(예시)
  • 또한 relnotes 이슈를 표시하여 T-release relnotes 도구가 처리할 수 있도록 합니다.
  • FCP도 이슈에서 시작될 경우 relnotes 이슈 생성을 유발합니다.
• metabug: 다른 버그들을 추적합니다.

팀 예시

이 섹션에서는 특정 팀에 배정되어야 하는 이슈 종류의 예시 목록을 제공합니다.

T-compiler

진단이나 ICE 등 컴파일러 구현과 관련된 모든 것

T-libs

• 라이브러리 함수의 구현 세부 사항 변경
• 라이브러리 문서의 철자, 문법, 구성상의 변경
• 함수 및 메서드와 같은 새로운 라이브러리 API
• 불안정 함수 시그니처 변경
• 특정 상황에서 함수가 특정 에러 코드를 생성함을 보장하는 것과 같이, 라이브러리 문서의 의미론적 변경
• 새로운 트레이트 구현 등 라이브러리 변경으로 인한 타입 추론 손상

T-lang

• 새로운 키워드/언어 기능
• 표준 라이브러리의 키워드 문서 변경 사항

T-spec

• reference에 대한 변경

T-opsem

• nomicon에 대한 변경
• 원자적 연산의 의미론과 같은, 추상 기계의 의미론에 대한 변경
• 안전하지 않은(unsafe) 포인터 함수 문서의 변경
• core::ptr 문서의 변경

레이블 생성

• 기존 레이블을 확인하여 중복되지 않도록 하십시오.
• 새 레이블이 관례에 어긋나거나 논란의 여지가 있을 수 있다면 https://rust-lang.zulipchat.com/#narrow/channel/242269-t-release.2Ftriage/topic/New.20labels에서 논의하십시오. 다른 사람들에게 참고가 되도록 새 레이블에 대한 코멘트를 남기십시오.

레이블 별칭

*별칭(aliases)*을 사용하면 한 번에 여러 레이블을 추가하거나 제거할 수 있습니다. 별칭에 대해 더 자세히 알아보려면 관련 문서를 방문하십시오.

Relnotes 이슈

릴리스 노트 이슈는 현재 기본적으로 needs-triage가 붙어서 생성됩니다. relnotes 트리아지는 보통 충분한 맥락이 있을 때 가장 잘 수행할 수 있습니다. 그렇지 않다면 그대로 두십시오.

• 실제 사용자 대상 relnotes와는 관계없이, 실제 PR과만 관련된 무관한 영역 A-* 레이블을 제거하십시오.
• 무관한 T-* 또는 WG-* 레이블을 제거하십시오.
• PR 작성자, 리뷰어 또는 관련 팀 구성원이 relnotes 문구를 확인했거나 변경했다면 needs-triage를 제거하십시오.

내부 컴파일러 오류(ICE) 이슈 트리아지

내부 컴파일러 오류(ICE)를 포함하는 이슈의 경우:

• 이슈에 I-ICE, T-compiler, C-bug 태그가 붙어 있는지 확인하십시오.
• 해당 이슈가 실제로 ICE인지, 아니면 I-crash나 I-hang으로 더 정확히 설명되는지 확인하십시오.
• rust의 이전(최신 stable 정도) 버전이라면 다음을 물어보십시오:
  • ICE가 beta와 최신 nightly에서 재현되는지 여부.
  • 더 이전 stable이라면, ICE가 최신 stable에서 재현되는지 물어보십시오.
• 중복 여부를 확인하되, 동일한 근본 이슈를 나타낸다고 확신하지 않는 한 중복으로 닫지 마십시오. 가능한 관련/중복 항목으로 단순히 해당 이슈에 링크를 남기는 편이 좋습니다.
  • ICE 메시지를 검색하는 것이 좋은 방법입니다. 동일한 ICE 메시지라도 근본 원인이 다를 수 있으므로 중복으로 닫을 때 주의하십시오.
• 재현 방법이 없다면, 재현 방법을 요청하는 댓글을 남기고 S-needs-repro를 추가하십시오.
  • 약 한 달 동안 재현 방법이 제공되지 않으면 일반적으로 닫아야 합니다.
• 재현 방법이 최소화되어 있지 않다면 E-needs-mcve를 추가하거나 직접 MCVE를 작성하십시오. MCVE 절차에 대한 자세한 내용은 “Initial triaging” 섹션을 참고하십시오.
• 이슈를 유발하는 코드(백트레이스를 확인하십시오!)와 재현 사례의 성격에 따라 A-* 라벨을 추가하십시오(예: 재현 사례가 이상한 트레이트 구현이거나 백트레이스가 rustc_trait_selection을 가리킨다면 A-traits를 추가합니다).
• 적절한 경우 T-*, WG-*, PG-*, F-*, requires-*, regression-* 레이블을 추가하십시오.
  • 보통 ICE는 T-compiler로 태그해야 합니다. 이슈가 타입 시스템(예: 트레잇 솔버)과 관련된다면 T-types로도 태그하십시오.
• rustdoc에서의 ICE라면 T-compiler 대신 T-rustdoc을 추가하십시오.

추가 트리아지

초기 트리아지 단계를 거친 이슈(즉, 더 이상 needs-triage 레이블이 없는 이슈)라도 대개 개선할 수 있는 부분이 여전히 남아 있습니다. 적용할 수 있는 레이블이 더 많이 있는 경우가 흔합니다(rust-lang/rust에 쓰기 권한이 없다면 다시 rustbot을 사용하십시오).

또한 오래된(아직 명확한 정의는 없지만 대략 몇 달 단위의) S-needs-repro 이슈는 재현 방법 없이는 더 이상 진전할 방법이 없다면 닫을 수 있습니다. 이 작업에는 rust-lang/rust에 대한 쓰기 권한이 필요하지만, 권한이 없다면 Zulip(예: t-release/triage나 general)에 이슈 링크를 남기면 쓰기 권한이 있는 누군가가 대신 닫아 줄 수 있습니다.

또 다른 유용한 작업으로는 E-needs-mcve 및 E-needs-bisection 이슈를 살펴보며 최소화 작업을 하거나 (cargo-bisect-rustc를 사용하여) 이슈를 비섹션하는 것이 있습니다.

• 이분 탐색 결과를 제공하실 때는 이분 탐색 상태 레이블을 조정하십시오: @rustbot label -E-needs-bisection +S-has-bisection.
• MCVE를 제공하실 때는 MCVE 상태 레이블을 조정하십시오: @rustbot label -E-needs-mcve +S-has-mcve.

1. O-* 레이블의 O는 원래 *운영체제(OS)*를 의미했습니다. ↩

2. I-* 레이블의 I는 원래 *중요도(importance)*를 의미했습니다. 이는 I-*-nominated 레이블에 가장 잘 들어맞습니다. 그러나 대부분의 I-* 레이블에서는 I를 *이슈(종류)*로 해석하는 것이 타당합니다. ↩

3. E-* 레이블의 E는 *경험(experience)*을 의미합니다. ↩