우선순위 지정

컴파일러 팀이 우선순위가 높은 이슈를 빠르게 파악할 수 있어야 합니다. 그래서 아래에서 설명하는 우선순위 지정 절차를 마련했습니다.

일반 절차

1. 이슈의 현재 상태를 확인하십시오
2. 가능하다면 이슈를 진전시켜 보십시오(예: 이슈 작성자나 리뷰어에게 진행 상황을 요청하십시오)
3. 이슈에 대한 MCVE가 이미 있습니까?
4. 회귀인지 확인하고 알맞은 레이블(regression-* 레이블)을 붙이십시오
5. 이슈가 속한 영역을 파악하고 알맞은 레이블(A-* 레이블)을 붙이십시오
6. 알림 그룹에 핑을 보내거나 관련 팀을 호출하십시오
7. 가능하다면 담당자를 지정하십시오

이슈의 우선순위 지정 요청하기

일반적으로 회귀 이슈와 건전성 문제(unsound) 및 잘못된 컴파일(miscompile) 이슈에 우선순위를 지정합니다.

누구든지 GitHub 댓글에 다음 명령을 남겨 이슈의 우선순위 지정을 요청할 수 있습니다:

@rustbot prioritize

또는 팀 구성원이라면 I-prioritize 레이블을 붙이기만 하면 됩니다.

저장소에서 이슈 우선순위 지정을 활성화하는 방법은 여기에서 자세히 확인하십시오.

이슈에 우선순위 지정하기

우선순위를 지정하려면 I-prioritize 레이블을 P-critical, P-high, P-medium, P-low 중 하나로 교체하고, 그 근거에 대한 간결한 댓글을 추가하거나 이슈 우선순위 지정이 이루어진 Zulip 논의를 링크하십시오. 예시는 다음과 같습니다:

우선순위를 지정합니다(Zulip에서 논의).

@rustbot label -I-prioritize +P-XXX

팁: Github Saved Replies를 사용하면 템플릿 댓글을 만들어 둘 수 있습니다.

Zulip에서도 우선순위를 지정할 수 있습니다:

@**triagebot** assign-prio <issue #> [ critical | high | medium | low | <empty>]

예시:

• 이슈 123456에 높은 우선순위 지정:

  @**triagebot** assign-prio 123456 high
  

• 이슈 123456의 우선순위 제거:

  @**triagebot** assign-prio 123456
  

우선순위 수준

컴파일러 팀의 자원은 한정되어 있으므로, 우선순위 지정의 주된 목표는 작업할 가치가 가장 큰 이슈를 가려내어 컴파일러 팀이 가장 중요한 일에 집중할 수 있도록 하는 것입니다.

레이블

이슈에 I-prioritize 레이블을 붙이면 우선순위 지정 절차가 시작되며, 이 절차는 I-prioritize 레이블을 제거하고 아래에서 설명할 레이블 4개 중 하나를 붙이는 것으로 끝납니다:

• P-critical
• P-high
• P-medium
• P-low

각 레이블은 다음 사항에 대해 팀이 취할 전략을 정의합니다.

• 해당 이슈가 받을 관심의 정도
• 커뮤니티 구성원이 참여할 수 있는 방법

P-critical

P-critical은 컴파일러 릴리스를 막을 가능성이 있는 이슈입니다(즉, 새 컴파일러 릴리스 전에 해결할 것을 강력히 권장하는 이슈입니다). 이러한 이슈는 매주 열리는 컴파일러 팀의 트리아지 회의에서 다루어집니다.

일반적으로 “critical” 버그로 판단하는 사례는 다음과 같습니다.

• 이전에 컴파일되던 코드가 더 이상 컴파일되지 않는 회귀
  • 우선순위를 낮출 수 있는 완화 조건:
    • 해당 코드가 애초에 컴파일되지 않았어야 하는 경우(다만 회귀가 많은 크레이트에 영향을 준다면 경고 기간이 필요하다는 신호일 수 있습니다)
    • 해당 코드가 이론적인 것에 불과해 실제로 존재할 가능성이 낮다고 판단되는 경우, 또는 널리 쓰이지 않고 관리되지 않는 소규모 패키지에만 존재하는 경우
  • 회귀가 한두 릴리스 동안 stable에 남아 있었다면(아직 수정을 기다리고 있기 때문이든, 버그가 잠복해 있어 발견되지 않았기 때문이든) 우리는 보통 우선순위도 낮춥니다. 그때까지 사용자들이 그 회귀에 대해 크게 문제를 제기하지 않았다면 그것은 본질적으로 치명적인 이슈가 아니라는 신호이기 때문입니다.
• 코드가 여전히 컴파일되지만 이전과 다르게 동작하는 회귀(동적 의미론이 변경된 경우)
  • 우선순위를 낮출 수 있는 완화 조건:
    • 코드가 명시적으로 규정되지 않은 기능을 사용하는 경우(예: std::vec::Vec 문서에는 요소를 drop하는 순서가 변경될 수 있다고 명시되어 있습니다)
• 기능 게이트 없이 접근할 수 있는, 기능 게이트로 보호된 기능
  • 우선순위를 낮출 수 있는 완화 조건:
    • 해당 패턴이 나타날 가능성이 매우 낮은 경우
• 실제 영향이 있는 건전성 결함
  • 우선순위를 낮출 수 있는 완화 조건:
    • 유발하기 어려운 건전성 결함
    • stable에 영향을 주지 않는 건전성 결함(예: 해당 결함이 게이트로 보호된 불안정 기능을 사용하는 경우).
• 진단이 매우 흔하게 발생하고 상황이 매우 혼란스러운 진단 회귀
• 흔한 시나리오나 코드 패턴에서 발생하는 ICE
  • 우선순위를 낮출 수 있는 완화 조건:
    • ICE를 유발하는 코드가 컴파일 오류도 유발하고, 그 오류가 ICE보다 먼저 출력되는 경우
    • 해당 코드가 불안정 기능을 사용하는 경우, 특히 ICE가 기능 게이트를 필요로 하는 경우

P-critical 이슈는 가장 많은 관심을 받습니다. 이 이슈는 가능한 한 빨리 한 명 이상의 담당자에게 배정되어야 하며, 나머지 팀원은 필요한 경우 최선을 다해 이들을 도와야 합니다.

P-high

P-high 이슈는 컴파일러 팀의 관심이 필요하지만, 매 회의에서 논의할 정도는 아닌 이슈입니다. 이러한 이슈는 위에서 정의한 완화 조건이 있는 P-critical 이슈일 수도 있고, 릴리스를 막는 이슈로 간주되지는 않지만 중요한 이슈일 수도 있습니다.

모든 컴파일러 회의에서 다루기에는 P-high 이슈가 너무 많으므로, 이러한 이슈가 진척될 수 있도록 팀의 우선순위 지정 작업을 통해 비동기적으로 처리하는 것이 좋습니다. 필요하다고 판단되는 경우에는 여전히 가끔 회의에서 다룰 수 있습니다.

팀의 우선순위 지정이 얼마나 효과적인지는 P-critical 이슈와 P-high 이슈 사이에 선을 긋는 능력에 직접적으로 달려 있습니다. 컴파일러 회의를 감당할 수 없을 만큼 P-critical 이슈가 많아서는 안 되지만, 그렇다고 치명적인 이슈가 P-high 이슈 목록 속에 묻혀서도 안 됩니다.

P-high 이슈는 팀이 주로 작업하게 될 이슈입니다. 이러한 이슈에는 반드시 담당자가 배정되도록 하고, 계속 주시하고자 합니다. 컴파일러 팀은 이러한 이슈를 정기적으로 일괄 검토하며, 이 과정에서 우선순위를 낮출지 결정합니다.

P-medium 및 P-low

P-medium은 팀의 우선순위는 아니지만 장기적으로 해결될 이슈를 가리킵니다. 예를 들어, 특정 기능이 반영된 후에 수정될 이슈가 이에 해당합니다. 이러한 이슈는 수정에 관심이 있는 사람을 팀이 멘토링할 수 있는 이슈입니다. 이러한 이슈는 누군가 문제를 제기하거나, 커뮤니티 구성원이 수정하거나, 우연히 수정될 때까지 이 상태로 남아 있습니다.

P-low는 컴파일러 팀이 해결할 계획은 없지만 그래도 수정할 가치가 있는 이슈를 가리킵니다. 이슈가 불분명하여 논의가 필요한 경우에는 해당 이슈를 상정하십시오.

컴파일러 트리아지

컴파일러 팀은 매주 목요일 Zulip에서 모여 트리아지를 진행하고 다른 주제에 대해서도 이야기를 나눕니다. 누구에게나 열려 있으니 자유롭게 참여하십시오.

트리아지 회의 안건은 우선순위 지정 작업의 결과를 입력으로 사용하여 생성되며, 그 방법은 여기에서 확인하십시오.