우선순위 지정

컴파일러 팀이 우선순위가 높은 이슈를 신속히 식별할 수 있는 것이 중요하며, 이에 따라 아래에서 설명하는 우선순위 지정 프로세스가 마련되었습니다.

일반 프로세스

이슈의 현재 상태를 파악합니다
가능하다면 이슈를 진전시켜 보십시오(예: 이슈 작성자/리뷰어에게 업데이트를 요청).
해당 이슈에 대한 MCVE가 이미 존재합니까?
회귀인지 확인하고 그에 맞게 레이블을 지정하십시오(regression-* 레이블).
이슈가 속한 영역을 파악하고 그에 맞게 레이블을 지정하십시오(A-* 레이블).
알림 그룹 또는 관련 팀에 핑을 보냅니다
가능하다면 담당자를 지정합니다

이슈에 대한 우선순위 지정 요청

일반적으로 회귀 이슈와 안전성 위반(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 저장된 답글을 사용할 수 있습니다.

우선순위는 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 문서에는 요소를 드롭하는 순서가 변경될 수 있다고 명시되어 있습니다)
기능 게이트 없이 접근 가능한 기능 게이트된 기능
- 우선순위를 낮출 수 있는 완화 조건:
  - 해당 패턴이 발생할 가능성이 매우 낮은 경우
실제 영향이 있는 건전성 결함
- 우선순위를 낮출 수 있는 완화 조건:
  - 유발하기 어려운 건전성 결함
  - stable에 영향을 미치지 않을 건전성 결함(예: 그 결함이 게이트된 unstable 기능을 사용하는 경우).
진단이 매우 흔하고 상황이 매우 혼란스러운 진단 회귀
흔한 시나리오나 코드 패턴에 대한 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에서 만나 트리아지를 진행하고 다른 주제에 대해서도 이야기를 나눕니다. 누구나 참여할 수 있으니 부담 없이 참여해 주십시오.

트리아지 미팅 안건은 우선순위 지정 작업 결과를 입력으로 하여 생성되며, 그 방법은 여기에서 확인할 수 있습니다.

Keyboard shortcuts

Rust Forge