11 KiB
Maintainers
English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語 · 한국어
이 문서는 nexu-io/open-design의 Maintainer가 되고, 그 역할을 맡고, 물러나는 규칙을 정합니다. Core Team의 개별 명단은 내부에서 관리하므로 여기에 적지 않습니다. 공개적으로 중요한 건 모두가 따르는 규칙 그 자체입니다.
상태: v1, 2026-05-11 초안 작성.
CONTRIBUTING.ko.md와 짝을 이루는 문서입니다. CONTRIBUTING.ko.md는 전체 규칙을 확인하려는 기여자를 이 문서로 안내합니다.
역할
| 역할 | 권한 |
|---|---|
| Contributor | 머지된 PR이 1건 이상인 모든 사람. 특별한 권한은 없습니다. |
| External Maintainer | 아래 규칙에 따라 승격된 커뮤니티 기여자. 리뷰, 승인, issue 닫기/다시 열기, issue 셀프 배정을 할 수 있습니다. 머지 버튼은 누를 수 없습니다 — 이 권한은 Core Team이 갖습니다. |
| Core Team | Open Design의 내부 팀. 저장소 전체 쓰기 권한을 갖고, 거버넌스 결정의 최종 권한을 가집니다. 명단은 내부에서 관리합니다. |
별도 언급이 없으면 이 문서의 나머지는 모두 External Maintainer에 관한 내용입니다.
Maintainer만 할 수 있고 Contributor는 할 수 없는 것
| 동작 | Contributor | Maintainer |
|---|---|---|
| PR 승인 | ⚠️ 단순 코멘트로 처리되며, 머지에 필요한 승인으로 인정되지 않음 | ✓ 머지에 필요한 승인으로 인정됨 |
| issue 닫기 / 다시 열기 | 본인이 연 issue만 | ✓ 모든 issue |
| 열려 있고 배정되지 않은 issue 셀프 배정(P0 우선) | ✗ | ✓ |
머지 조건
PR은 누가 작성했든 다음 세 가지를 모두 만족해야 합니다.
- 코드 충돌이 없을 것.
- CI가 완전히 통과(green)할 것.
- Maintainer 또는 Core Team 멤버의 승인이 최소 1건 있을 것.
대부분의 PR은 Maintainer의 승인을 거쳐 머지됩니다. Maintainer의 신뢰가 프로젝트의 일상에 가장 직접적으로 드러나는 방식입니다.
Maintainer가 되는 방법
진입 조건은 세 가지이며, 모두 충족해야 합니다.
1. 기여량
nexu-io/open-design에 머지된 PR 20건 이상.
이 수치는 자동 통과 기준이 아니라 최소선입니다. PR 20건을 넘기면 검토 대상에 오를 뿐, 역할이 보장되지는 않습니다.
2. 계정 신뢰도(다중 계정·봇 방지)
후보의 GitHub 프로필을 일곱 가지 항목으로 점검합니다. 7개 중 5개 이상의 통과 기준을 만족하고, 거부 기준은 하나도 건드리지 않아야 합니다.
| # | 항목 | 통과 기준 | 거부 기준 |
|---|---|---|---|
| 1 | GitHub 계정 나이 | 1년 이상 | 90일 미만 |
| 2 | 공개 저장소 | 3개 이상 | 0개 |
| 3 | 팔로워 | 10명 이상 | 3명 미만 |
| 4 | 팔로워 / 팔로잉 비율 | 0.30 초과 | 0.05 미만(전형적인 팔로우 농장 패턴) |
| 5 | 프로필 완성도 | 커스텀 아바타 그리고 bio / company / blog / twitter 중 하나 이상 | 기본 아바타 그리고 bio·company·blog가 모두 비어 있음 |
| 6 | 다른 프로젝트 활동 | 다른 공개 저장소에 머지된 PR이 하나 이상 있거나, issue/star 활동이 꾸준함 | 머지된 PR이 이 저장소에만 있음 |
| 7 | 계정 상태 | GitHub 플랫폼 제재 이력 없음(스팸/차단/복구) | 위 항목 중 하나라도 해당 |
초기 프로젝트 면제(저장소가 6개월이 되면 자동 만료)
nexu-io/open-design이 최초 커밋으로부터 6개월 미만인 동안에는, 다음 조건에서 다른 프로젝트 활동(#6) 거부 기준을 Core Team 합의로 면제할 수 있습니다.
- 항목 1, 2, 3, 5가 통과 기준을 명확히 넘을 것, 그리고
- 이 저장소에서의 PR 품질이 Core Team의 직접 리뷰로 높게 평가될 것.
면제할 때는 후보 이름과 날짜를 Core Team 내부 기록에 함께 남깁니다. 저장소가 6개월에 도달하면 이 면제 조항은 더 이상 적용되지 않습니다.
3. 기여 품질(Core Team 판단)
정성적인 평가이며 공식에 따르지 않습니다. Core Team은 다음을 봅니다.
- 머지된 PR의 코드 품질(정확성, 작업 범위 준수, 저장소 경계 존중).
- 다른 사람의 PR에 남긴 리뷰 코멘트의 리뷰 품질.
- 커뮤니티 참여 — Discussions, issue 분류, Discord 활동.
- 협업 신호 — 피드백에 대한 반응, 기꺼이 수정하려는 자세.
앞의 두 조건을 통과하면 후보군에 들어갑니다. 이 세 번째 기준을 넘어서야 지명을 받습니다.
선정 절차
- Core Team 멤버가 내부에서 후보를 제안합니다.
- Core Team이 합의에 이릅니다.
- Core Team 멤버가 비공개로 연락해 후보의 의사를 확인합니다.
- 온보딩.
- 공개 발표.
지명 PR도, 공개 투표도, 정해진 임기도 없습니다. 이는 의도적으로 K8s/Apache의 승인자 투표 모델을 뒤집은 방식입니다. 프로젝트 초기에는 가벼운 Core Team 합의가 더 빠르게 움직이면서도 같은 수준의 결과를 냅니다. Maintainer 인원이 External Maintainer 다섯 명을 넘어 늘어나면 이 부분을 다시 검토합니다.
책임과 기대
엄격한 할당량은 없습니다. 주간 PR 리뷰 횟수도, 최소 issue 분류 비율도, 응답 시간 SLA도 없습니다. Maintainer는 신뢰의 인정이지, 보수 없는 업무가 아닙니다.
다만 원칙적으로 부탁드리는 것은 다음과 같습니다.
- 맥락을 아는 PR은 승인하고, 모르는 PR은 판단을 보류하세요.
- 머지 조건(§"머지 조건")을 지키세요. 당신의 승인은 형식적인 도장이 아니라 실질적인 신호입니다.
- 오랜 기간 자리를 비울 때는
#maintainers에 알려 주세요. #maintainers에서 공유되는 미공개 로드맵은 기밀로 다뤄 주세요.
Core Team이 나쁜 행태(형식적 승인, 악의적 issue 닫기, 미공개 로드맵 유출 등)의 패턴을 확인하면, §"사유 기반 사임"에 따라 권한을 회수합니다.
Maintainer 전용 접근 권한
위에 적은 저장소 권한 외에도, Maintainer는 일반 커뮤니티가 받지 못하는 몇 가지를 받습니다.
- Discord
#maintainers채널 — Core Team과 공유하는 비공개 작업 공간. 디자인 미리보기, RFC 초안, 그리고 아직 공개되지 않은 로드맵에 대한 내부 조율에 씁니다. - 기밀 로드맵 — 아직 발표되지 않은 작업을 미리 볼 수 있습니다. Maintainer는 Core Team 멤버가 공개로 발표하기 전까지 그 내용을 기밀로 다루기로 합의합니다.
- Core Team과의 직통 라인 —
#maintainers메시지는 공개 Discussions보다 더 빠르고 충실한 답을 받습니다. Core Team은 아키텍처와 로드맵 결정에 Maintainer의 의견을 진심으로 구합니다. - Maintainer 배지 — GitHub 프로필과 MAINTAINERS 관련 저장소 화면에 표시되는 공개 신뢰 표식(GitHub 배지 기능이 준비되는 대로 적용).
- 승격 시 공개 인정 — 합류할 때 Twitter, GitHub Discussions, Discord에서 발표합니다.
사임
Maintainer는 종신직이 아닙니다. 세 가지 퇴장 경로가 있습니다.
자발적 사임(스스로)
- Maintainer가 Core Team에 메시지를 보내거나
#maintainers에 글을 올립니다. - 권한은 24시간 안에 회수됩니다.
- 해당 Maintainer는 Emeritus 상태로 전환됩니다.
- 공개적인 사유는 필요 없습니다.
비활동 전환
다음 중 하나라도 해당하면 비활동 전환 대상으로 검토합니다.
- 활동 신호(머지된 PR, 리뷰 코멘트, issue 분류, 비중 있는 Discussion이나 Discord 참여)가 90일 연속 없거나, 또는
- @ 멘션(PR 리뷰 요청, issue 배정)에 60일 연속 응답이 없음.
절차:
- Core Team이
#maintainers에서 해당 Maintainer를 비공개로 @ 멘션하고, 14일의 응답 기간을 줍니다. - 14일 안에 의미 있는 응답이 없으면 Emeritus로 전환되고 권한이 회수됩니다.
- GitHub Discussions에 짧고 따뜻한 공개 안내를 올립니다: "그동안의 기여에 감사합니다. Emeritus로 전환되었으며, 언제든 다시 돌아오셔도 좋습니다."
- 복귀는 쉽습니다 — 아래 "Emeritus"를 참고하세요.
사유 기반 사임
다음에 의해 발동됩니다.
- 반복되는 나쁜 행태(예: 함량 미달 PR에 대한 형식적 승인, 악의적 issue 닫기, 권한 남용).
- 프로젝트 행동 강령 위반.
- 보안 등급의 사고(계정 탈취를 즉시 보고하지 않음, 미공개 로드맵 고의 유출 등).
절차:
- Core Team 멤버는 누구나 논의를 시작할 수 있습니다.
- 조치를 취하기 전에 Core Team 멤버 3명 이상이 동의해야 합니다(Core Team 전원 합의까지는 필요하지 않습니다).
- 결정 후 24시간 안에: 권한 회수,
#maintainers에서 제외, 모든 Maintainer 명단에서 제거(Emeritus로 전환되지 않습니다). - 당사자에게 결정과 사유를 알리며, 한 차례 이의를 제기할 수 있습니다.
원칙은 Maintainer를 가급적 유지하는 쪽입니다. 작은 실수 한 번은 강제 사임의 사유가 되지 않습니다. 사유 기반 경로는 반복되는 패턴이나 심각한 일회성 사고에만 적용합니다.
Emeritus
자발적으로 사임하거나 비활동으로 전환된 Maintainer는 Emeritus가 됩니다. Emeritus 상태는 다음과 같습니다.
- 쓰기/승인/닫기 권한을 회수합니다.
- (내부) 명단의 Emeritus 항목에 이름을 남겨 공로를 기립니다.
- Discord
#maintainers접근 권한을 유지합니다(읽기든 글쓰기든 Maintainer가 선택). - 이어지는 책임은 없습니다.
Emeritus에서 복귀
가장 간단한 복귀 경로: 최근 30일 안에 머지된 PR 3건. 그러면 Core Team이 권한을 복원합니다. 다시 지명받을 필요는 없습니다.
Emeritus의 취지는 인생에는 늘 일이 생긴다는 점을 인정하는 것입니다. 안식년, 이직, 육아 같은 일을 양쪽 모두에게 아무런 부담이나 사회적 비용 없이 받아들이려는 것입니다.
이 문서의 변경
이 문서의 규칙은 Core Team 합의로 개정할 수 있습니다. 중대한 변경(진입 조건, 사임 기준)은 활동 중인 후보에게 적용되기 전에 GitHub Discussions에 발표합니다. 편집상의 명확화는 곧바로 반영할 수 있습니다.