프로젝트 그룹

소개

프로젝트 그룹은 특정 프로젝트를 완수하는 것을 목표로 작업하도록 만들어진 일종의 Rust 팀입니다. 이는 RFC 2856에서 처음 정의되었습니다. 요약하면 다음과 같습니다:

• 프로젝트 그룹은 (RFC와 같은) 팀 합의를 통해 생성되며 “상위 팀(들)“을 가집니다.
• 이후 그룹은 후속 RFC를 작성하거나 설계 작업을 수행하는 등의 방식으로 프로젝트를 완료로 이끕니다.
• 작업이 마무리되면 그룹은 아카이브됩니다.
• 각 프로젝트 그룹은 일반적으로 다음을 갖추고 있습니다:
  • 그룹의 범위와 목표를 개괄하는 헌장.
  • 임명된 셰퍼드와 팀 리에종.
  • 관련 저장소.
  • Zulip 등에 마련된 전용 스트림.

프로젝트 그룹 정의

프로젝트 그룹은 공식 Rust 팀의 요청에 따라 특정 프로젝트나 책무를 수행하는 사람들의 모임입니다. 일부 프로젝트 그룹은 일시적이며, 프로젝트가 완료되면 아카이브된다는 것을 의미합니다. 하지만 지속적인 작업과 유지 관리가 이루어지는 프로젝트 그룹도 있습니다.

특정 기능을 중심으로 한 프로젝트 그룹의 예로는 FFI Unwind, Inline ASM, Safe Transmute가 있습니다.

프로젝트의 목표는 조직 내 특정 기능이나 프로젝트를 중심으로 커뮤니티를 구축하거나 기존 커뮤니티를 공식화하고, 이 공간을 활용해 해당 기능에 대해 논의하고 반복적으로 개선해 나가는 것입니다.

커뮤니티 구축의 일환으로, 설계 과정에서 형성되는 조직 내 암묵지 일부를 제거하고 기능과 관련된 정보와 논의를 한곳에 집중시켜, 특정 결정과 절충안이 다른 것보다 선택된 이유를 더 잘 파악할 수 있도록 합니다.

이전에는 대규모 기능에 대한 많은 논의와 반복 작업이 최초 RFC 스레드에서 이루어지곤 했습니다. 이로 인해 스레드 상단에 많은 논의가 쌓이게 되고, 이는 종종 현재 반복 작업과는 완전히 무관해집니다.

이러한 과정은 개발에 수년이 걸리고 설계 과정에서 여러 개의 RFC로 이어질 수 있는 기능을 설명하는 데도 적합하지 않았습니다. 이에 대한 예로는 “impl Trait“와 “매크로 2.0” 기능이 있으며, 이들의 목표는 최초 RFC에서 많이 바뀌어서 현재 상태를 파악하기 어려울 수 있습니다.

프로젝트 그룹 생성

프로젝트 그룹은 다음을 갖추어야 합니다.

• 리드(Leads) — 그룹의 리더 역할을 하는 최소 한 명 이상의 인원으로, 일반적으로 초기 헌장 작성, 행정 및 커뮤니케이션 업무 처리, 그리고 이러한 책임을 그룹 내 다른 구성원에게 위임하는 일을 담당합니다.
• 연락 담당자(Liaisons) — 해당 작업을 후원하는 공식 Rust 팀의 구성원으로, 팀과 그룹 사이의 연락 창구 역할을 합니다. 이들은 직접적으로 깊이 관여하지 않을 수도 있지만, 주기적으로 상황을 확인하고 팀과의 회의에서 작업을 대표할 수 있어야 합니다. 또한 이 작업이 워킹 그룹 자체를 넘어 팀 내에서 진행 중인 다른 작업과 교차할 수 있는 시점을 주시해야 합니다.
  • 리에종은 리드 중 한 명일 수도 있지만, 반드시 그럴 필요는 없습니다.
• 구성원(Members) — 프로젝트 그룹에 정기적으로 참여하거나 기여하는 개인들입니다.
  • 그룹의 구성원 자격 요건은 셰퍼드가 결정하며 헌장에 명시되어야 합니다.
  • 초기 구성원은 해당 분야에서 이미 정기적으로 생산적으로 참여해 온 사람들을 대표하려고 노력해야 합니다.
  • 다만 프로젝트 그룹이 반드시 많은 구성원을 가질 필요는 없으며, 일부 프로젝트 그룹은 리드와 연락 담당자를 포함해 단 한두 명의 구성원만 있을 수도 있습니다.
• 그룹의 범위와 취지를 정의하는 헌장.
• rust-lang 조직 아래에 호스팅되는 GitHub 저장소로, 헌장과 커뮤니티 구성원이 그룹을 모니터링하거나 참여할 수 있는 방법에 대한 안내를 포함합니다.
• 공식 rust-lang.org 웹사이트에서의 대표성.
• *“공식적인 의사결정 권한”*은 없습니다: 즉 rust-lang/rfcs에서 RFC를 승인할 수 없다는 의미입니다.
  • 그룹은 물론 RFC를 작성하고 Rust 팀 및 커뮤니티에 우려 사항과 원하는 변경 사항을 알리는 것이 권장됩니다.
• Rust가 공식적으로 관리하는 토론 플랫폼 내의 전용 공간.
  • 이 글을 작성하는 시점 기준으로는 Zulip입니다.
  • 소통을 원활히 하기 위해 그룹은 이상적으로는 상위 팀과 같은 플랫폼을 사용해야 하지만, 팀이 그룹의 다른 플랫폼 시도에 동의하는 경우도 있을 수 있습니다.

헌장 작성하기

프로젝트 그룹은 해당 상위 팀의 승인을 받으므로, 구체적인 요건을 정하는 것은 각 팀에 달려 있습니다. 다만 저자는 그룹이 다음 질문들에 답하는 헌장을 작성해 보기를 권장합니다.

• 여러분의 그룹이 조직에 가져다줄 가치는 무엇이라고 생각하십니까?
• Rust 조직으로부터 필요로 하는 지원과, 별도로 원하는 지원은 무엇입니까?
• 왜 이것이 커뮤니티 활동이 아니라 프로젝트 그룹이어야 합니까?
• 여러분의 그룹의 목표는 무엇입니까?
  • 단기적으로도, 관련이 있다면 더 긴 기간에 걸쳐서도 마찬가지입니다.
• 여러분의 그룹이 명시적으로 목표로 삼지 않는 것은 무엇입니까?
• 팀과의 관계가 어떻게 되기를 기대하십니까?
• 여러분의 작업을 그룹 외부 사람들에게 어떻게 접근 가능하게 만들 계획입니까?
• 초기 셰퍼드/리더는 누구입니까? (2~3명이 바람직하지만 필수는 아닙니다.)
• 여러분의 그룹은 장기적으로 운영됩니까, 아니면 일시적입니까?
• 일시적이라면 얼마나 오래 운영될 것으로 예상하십니까?
  • 여러분의 그룹의 장기적인 비전은 무엇입니까?
• 해당되는 경우, 어떤 다른 그룹이나 팀과 긴밀히 접촉할 것으로 예상하십니까?
• 여러분의 그룹이 어디에서 도움이 필요할 것으로 보십니까?

초기 설정

그룹이 승인되면, 초기 구성원 명단을 담은 풀 리퀘스트를 rust-lang/team에 제출해야 합니다. 그룹을 생성하는 방법에 대해서는 team의 문서를 참조하십시오.

이후 프로젝트 그룹은 project group template을 사용하여 rust-lang 조직 아래에 저장소를 생성하고, 필요한 변경 및 개인화 작업을 수행하는 것이 권장됩니다.

평가

상위 팀은 정기 트리아지의 일환으로 프로젝트 그룹과의 확인 절차를 추가해야 합니다. 프로젝트 그룹은 또한 진행 상황 업데이트와 회의록을 “Inside Rust” 블로그에 블로그 게시물로 올리는 것이 권장됩니다.

아카이빙

어느 시점에서는 그룹의 작업이 종료됩니다. 작업이 완료되었거나, 구성원들이 작업을 끝낼 수 없거나, 그룹이 프로젝트를 더 이상 진행할 가치가 없다고 느끼기 때문입니다. 저자는 이 과정을 “아카이빙“이라고 부르고 있습니다.

공지

아카이빙을 고려하는 그룹은 먼저 자신들이 시작한 크레이트, 저장소, 또는 프로젝트에 어떤 일이 일어나야 하는지를 파악해야 합니다. 일반적으로 이러한 프로젝트는 다른 그룹이나 개인에게 이관되어야 하며, 프로젝트를 유지 관리할 적절한 후보가 없다면 아카이빙되어야 합니다.

이 문제가 해결되고 나면 그룹은 프로젝트의 이관 및/또는 아카이빙과 관련된 세부 사항과 함께 아카이빙 공지를 작성해야 합니다.

회고

이 RFC는 조직 내 현재의 몇 가지 조직적 문제를 해결하고자 시도하지만, 저자는 이것이 그러한 문제들에 대한 만병통치약이 되리라고도, 우리가 앞으로 새로운 문제를 겪지 않으리라고도 믿지 않습니다. 그 일환으로, 이 RFC는 상당한 시간이 지났거나 그룹이 프로젝트를 마쳤을 때 그룹과 함께 회고를 진행하는 것을 도입합니다.

여기에는 그룹 구성원들 간의, 그리고 이상적으로는 상위 팀과 거버넌스 워킹 그룹 간의 논의가 포함될 것입니다. 회고는 Inside Rust 블로그에 공개 게시물을 산출해야 하지만, 구성원이 비공개로 유지하고자 하는 피드백은 생략됩니다.

블로그 게시물은 RFC나 프로젝트 같은 그룹의 산출물뿐만 아니라, 그룹이 무엇이 잘 되었다고 생각했는지, 그리고 중요하게는 무엇이 잘 되지 않았는지를 다루려고 노력해야 합니다. 이는 우리가 이 초기 RFC를 반복적으로 개선하고, 그 과정에서 발생하는 이슈를 찾아 해결하는 데 도움이 되어야 합니다.

회고와 아카이빙 공지는 모두 하나의 게시물로 작성될 수 있으며, 아마도 그렇게 하는 것이 바람직할 것입니다. 다만 시기적절한 회고를 진행하는 것이 불가능한 경우도 있을 것이며, 그런 경우에는 더 짧은 별도의 공지 게시물이 적절합니다.

프로젝트 그룹의 생명 주기

이는 프로젝트 그룹의 전체 과정에 대한 높은 수준의 개요입니다.

Figure 1. Project Group Lifecycle

단계

1. 탐색 기간.

   • 문제 영역에 대한 초기 논의.
     • 팀은 초기 논의를 살펴보거나 응답할 의무가 없습니다. 물론 관심 있는 구성원은 자유롭게 참여할 수 있습니다.
   • 프로젝트에 대한 짧은 동기를 작성하십시오.
   • 연락 담당자 역할을 맡을 의향이 있는 사람을 관련 팀에서 찾으십시오.
     • 연락 담당자를 찾는 방식은 팀마다 다르므로, 프로젝트 그룹을 제안하는 방법에 대해서는 해당 팀의 문서를 참고해야 합니다.
     • 연락 담당자 역할을 맡을 의향이 있는 사람을 항상 찾을 수 있는 것은 아닙니다. 각 팀이 얼마나 많은 새로운 활동을 감당할 여력이 있는지는 각 팀이 결정할 사안이며, 때로는 그 여력이 전혀 없을 수도 있습니다.

2. 그룹을 만들기 위해 팀의 합의를 얻습니다.

   • 연락 담당자와 셰퍼드를 명시하십시오. (프로젝트 그룹 생성 참고)
   • 간단한 동기와 가능한 해결책에 대한 메모를 작성하십시오.
   • 합의에 도달하는 방식은 팀마다 다르며, 어떤 팀은 RFC를 요구하는 반면 다른 팀은 회의에서 결정할 수도 있습니다.

3. 그룹을 위한 인프라를 만듭니다.

   • 초안 RFC 등 작업과 논의를 진행하기 위한 rust-lang 산하의 GitHub 저장소.
   • 소통을 위한 Zulip 스트림입니다.
   • rust-lang/team의 프로젝트 그룹이며, 권한 처리를 위해 GitHub상의 팀이기도 합니다.

4. Inside Rust 블로그에 그룹 생성을 알리는 글을 작성하십시오. 다음 정보를 반드시 포함해야 합니다. 다음 정보를 반드시 포함하십시오.

   • 소개
   • 헌장(링크로 연결하거나 본문에 포함) [헌장 작성하기 참고]
   • 그룹의 GitHub 저장소 링크
   • 그룹이 참여자에게 열려 있다면, 어떻게 기여할 수 있는지에 대한 정보를 제공하십시오.
     • 정기 회의도 진행할 계획이라면, 그룹이 언제 모일 예정인지와 회의 캘린더 이벤트 링크를 함께 포함하십시오.

5. 그룹은 자신의 헌장에 명시된 목표를 향해 나아갑니다.

6. 활발한 작업이 중단되면 그룹은 “보관(archived)“됩니다.

   • 보관(archival)은 필요한 경우 프로젝트 그룹의 셰퍼드, 연락 담당자, 또는 상위 팀의 리드가 시작할 수 있습니다.
   • 보관이 반드시 영구적인 상태를 의미하지는 않으며, 이는 단지 그룹의 현재 상태를 반영할 뿐입니다.
     • 마찬가지로 그룹의 보관이 해당 영역의 작업이 모두 소진되었음을 의미하지는 않습니다
   • 보관하는 이유(완전한 목록은 아님):
     • 그룹 내 아무도 더 이상 시간을 낼 수 없거나 더 우선순위가 높은 일이 생겼습니다.
     • 해결할 수 없는 차단 이슈가 있습니다.
     • 가까운 미래에 이 영역에서 추가로 할 작업이 보이지 않습니다.
     • 작업이 만족스러운 수준까지 완료되었습니다.
     • 그룹이 결국 그 아이디어가 그다지 좋지 않았다고 판단했습니다.

7. 그룹의 보관을 알리는 블로그 게시물을 작성하십시오.

   • 이 게시물의 범위는 그룹의 범위에 따라 다르지만, 이상적으로는 다음 사항 중 일부를 포함해야 합니다.
     • 그룹이 만들어낸 결정, RFC, 그 밖의 산출물에 대한 개요.
     • 진행 과정에 대한 소감, (경우에 따라) 그것이 어떻게 작동했는지 혹은 작동하지 않았는지, 겪은 어려움, 그리고 개선하고 싶었던 점.

8. 인프라를 보관합니다.

   • GitHub 저장소를 읽기 전용으로 보관합니다.
   • 어떤 플랫폼에서든 채팅 채널을 보관하십시오.