프로젝트 그룹

소개

프로젝트 그룹은 특정 프로젝트를 완수하는 것을 목표로 해당 프로젝트를 수행하는 Rust 팀의 한 형태입니다. 프로젝트 그룹은 RFC 2856에서 처음 정의되었습니다. 요약하면 다음과 같습니다.

• 프로젝트 그룹은 팀의 합의(예: RFC)를 통해 만들어지며 하나 이상의 “상위 팀“을 가집니다.
• 이후 그룹은 후속 RFC 작성, 설계 작업 등을 통해 프로젝트를 완료까지 이끕니다.
• 작업이 마무리되면 그룹은 보관 처리됩니다.
• 각 프로젝트 그룹은 일반적으로 다음을 갖춥니다.
  • 그룹의 범위와 목표를 정리한 헌장.
  • 임명된 셰퍼드와 팀 연락 담당자.
  • 관련 저장소.
  • Zulip 등의 전용 스트림.

프로젝트 그룹 정의

프로젝트 그룹은 공식 Rust 팀의 요청에 따라 특정 프로젝트나 업무를 수행하는 사람들의 그룹입니다. 일부 프로젝트 그룹은 한시적이어서, 프로젝트가 완료되면 보관 처리됩니다. 그러나 지속적인 작업과 유지 관리를 맡는 프로젝트 그룹도 있습니다.

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

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

커뮤니티를 만드는 일에는 설계 과정에서 생겨나는 조직 내 암묵적 기억을 일부 걷어내고, 기능에 관한 정보와 논의를 한곳에 모아 특정 결정과 절충안이 다른 대안보다 왜 선택되었는지를 더 잘 드러내는 일이 포함됩니다.

이전에는 대규모 기능에 관한 논의와 반복 작업의 상당 부분이 최초 RFC 스레드에서 이루어졌습니다. 이로 인해 스레드 앞부분에 많은 논의가 쌓이게 되며, 그 논의는 현재 반복 단계와 전혀 무관해지는 경우가 많습니다.

또한 이 절차는 개발에 여러 해가 걸리고 설계 과정에서 여러 RFC로 나뉘게 되는 기능을 설명하는 데에도 적합하지 않았습니다. 그 예로는 “impl Trait” 기능과 “macros 2.0” 기능이 있으며, 이들은 최초 RFC에서 목표가 크게 바뀌어 현재 상태를 파악하기 어려울 수 있습니다.

프로젝트 그룹 생성

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

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

헌장 작성하기

프로젝트 그룹은 관련 상위 팀의 승인을 받으므로, 구체적인 요건은 각 팀이 결정합니다. 다만 필자는 그룹이 다음 질문에 답하는 헌장을 작성하도록 노력할 것을 권장합니다.

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

초기 설정

그룹이 승인되면 초기 구성원 목록을 담은 풀 리퀘스트를 rust-lang/team에 올려야 합니다. 그룹을 만드는 방법은 팀 문서를 참고하십시오.

그런 다음 프로젝트 그룹은 프로젝트 그룹 템플릿을 사용하여 rust-lang 조직 아래에 저장소를 만들고, 필요한 변경과 맞춤 설정을 하는 것이 권장됩니다.

평가

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

보관

언젠가는 그룹의 작업이 마무리될 것입니다. 작업이 완료되었기 때문일 수도 있고, 구성원들이 작업을 끝낼 수 없기 때문일 수도 있으며, 그룹이 프로젝트를 더 이상 추진할 가치가 없다고 느끼기 때문일 수도 있습니다. 필자는 이 과정을 “보관“이라고 부릅니다.

공지

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

이 문제가 해결되면 그룹은 프로젝트의 이관 및/또는 보관에 관한 세부 사항과 함께 그룹의 보관 공지를 작성해야 합니다.

회고

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

회고에는 그룹 구성원들 간의 논의가 포함되며, 이상적으로는 상위 팀과 거버넌스 워킹 그룹도 함께 참여합니다. 회고의 결과로 Inside Rust 블로그에 공개 블로그 게시물을 작성해야 합니다. 다만 구성원이 비공개로 남기고 싶어 하는 피드백은 제외합니다.

블로그 게시물에서는 RFC나 프로젝트 같은 그룹의 결과물과 함께, 그룹이 효과적이었다고 생각한 점, 그리고 중요하게는 효과적이지 않았던 점을 다루도록 해야 합니다. 이는 이 초기 RFC를 반복적으로 개선하고, 그 과정에서 발생하는 문제를 찾아 해결하는 데 도움이 될 것입니다.

회고와 보관 공지는 하나의 게시물로 작성할 수 있으며, 그렇게 하는 것이 바람직할 것입니다. 그러나 회고를 적시에 진행하기 어려운 경우도 있을 것이며, 그런 경우에는 별도의 짧은 공지 게시물을 작성하는 것이 적절합니다.

프로젝트 그룹의 생애 주기

다음은 프로젝트 그룹의 전체 과정에 대한 개략적인 설명입니다.

그림 1. 프로젝트 그룹 생애 주기

단계

1. 탐색 기간.

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

2. 그룹을 만드는 데 대해 팀의 합의를 얻으십시오.

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

3. 그룹을 위한 인프라를 만드십시오.

   • RFC 초안 등 작업과 논의를 호스팅하기 위한 rust-lang 아래의 GitHub 저장소.
   • 소통을 위한 Zulip 스트림.
   • 권한 관리를 위한 rust-lang/team의 프로젝트 그룹과 GitHub의 팀.

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

   • 소개
   • 헌장(링크 또는 본문 포함) [헌장 작성하기 참조]
   • 그룹의 GitHub 저장소 링크
   • 그룹이 참여자에게 열려 있다면 기여 방법에 관한 정보를 제공하십시오.
     • 정기 회의도 진행할 계획이라면 그룹의 회의 일정과 함께 회의 캘린더 일정 링크를 포함하십시오.

5. 그룹은 헌장에 명시된 목표를 향해 활동합니다.

6. 활발한 작업이 중단되면 그룹은 “보관” 상태가 됩니다.

   • 보관은 프로젝트 그룹 셰퍼드나 연락 담당자가 시작할 수 있으며, 필요한 경우 상위 팀의 리드가 시작할 수도 있습니다.
   • 보관이 반드시 영구적인 상태인 것은 아니며, 그룹의 현재 상태를 반영할 뿐입니다.
     • 마찬가지로 그룹이 보관되었다고 해서 해당 분야의 작업이 모두 끝났다는 뜻은 아닙니다.
   • 보관 사유(일부 예시):
     • 그룹의 누구에게도 더 이상 시간이 없거나 우선순위가 더 높은 일이 생겼습니다.
     • 해결할 수 없는 차단 이슈가 있습니다.
     • 가까운 미래에 이 분야에서 추가로 할 작업이 보이지 않습니다.
     • 작업이 만족스러운 수준까지 완료되었습니다.
     • 그룹이 결국 그 아이디어가 그다지 좋지 않다고 판단했습니다.

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

   • 이 글의 범위는 그룹의 범위에 따라 달라지지만, 다음 중 일부를 포함하는 것이 이상적입니다.
     • 그룹이 만들어 낸 결정, RFC 및 기타 산출물의 개요.
     • 진행 과정에 대한 소감, 즉 과정이 어떻게 진행되었는지(또는 경우에 따라 잘 진행되지 않았는지), 겪은 어려움, 그리고 개선되었으면 하는 점.

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

   • GitHub 저장소를 읽기 전용으로 보관 처리합니다.
   • 모든 플랫폼의 채팅 채널을 보관 처리합니다.