サニックコミュニティ組織ポリシーE-manual

2019年12月、バージョン1

目標

Sanicプロジェクトを中心に、持続可能なコミュニティ主導の組織を作り、それを推進すること: (1) 安定性と予測可能性、(2) 迅速な反復と強化サイクル、(3) 外部貢献者の関与、(4) 全体的に信頼できるソフトウェア、(5) コミュニティメンバーにとって安全でやりがいのある環境、などを推進するコミュニティ主導の組織を作る。

概要

本ポリシーは、Sanic Community Organization（以下、「SCO」という）の経営モデルである。SCOは、実力主義、合意主義に基づくコミュニティ組織で、採択されたすべてのプロジェクトに責任を持ちます。いずれかのプロジェクトに興味を持つ人は誰でもコミュニティに参加し、コミュニティやプロジェクトに貢献し、意思決定プロセスに参加することができます。この文書では、その参加方法と、プロジェクト・コミュニティ内で功労を得るための方法について説明します。

構造

SCOには複数のプロジェクトがあります。各プロジェクトは、Sanic コミュニティ傘下の単一の GitHub リポジトリによって表現されています。これらのプロジェクトはユーザによって使用され、貢献者によって開発され、コア開発者によって管理され、リリースマネージャによってリリースされ、最終的に運営評議会によって監督される。もしこれがPythonプロジェクトやPEP 8016に似ていると思われるなら、それは意図的にそのように設計されているからです。

役割と責任

ユーザー

ユーザーは、プロジェクトに必要なコミュニティメンバーです。彼らは、開発者であり、パッケージをダウンロードしインストールする人員でもあります。ユーザーはコミュニティの 最も重要な メンバーであり、彼らなしではプロジェクトは目的を持ちません。ユーザーは誰でもなることができ、プロジェクトが採用するライセンスは適切なオープンソースライセンスでなければならない。

SCOは、ユーザーにできるだけプロジェクトやコミュニティに参加するよう求めています。

ユーザーの貢献により、プロジェクトチームは、そのユーザーのニーズを確実に満たすことができるようになります。一般的なユーザー貢献には、以下のようなものがある（ただし、これらに限定されない）。

• プロジェクトについての伝道（例：ウェブサイト上のリンク、口コミによる認知度の向上）
• 新しいユーザーの視点から、開発者に長所と短所を知らせる。
• 精神的なサポート（"ありがとう"の一言が大きな力になります）
• 金銭的な支援（オープンソースのソフトウェアですが、開発者は食べていく必要があります。）

SCO、そのプロジェクト、そのコミュニティに関わり続けるユーザーは、多くの場合、より深く関わるようになります。そのようなユーザは、次のセクションで説明するように、自分自身が貢献者になることに気づくかもしれません。

コントリビューター

コントリビューターは、1つまたは複数のプロジェクトに具体的な方法で貢献するコミュニティのメンバーです。誰でもコントリビューターとなることができ、コントリビューターにはさまざまな形態があります。貢献と要件は、各プロジェクトが個別に定める貢献ポリシーによって管理されます。

プロジェクトに対するコミットメントを期待せず、特定のスキルを要求せず、選考過程も行いません。

また、ユーザーとしての活動だけでなく、以下のような活動も行っている場合があります。

• 新規ユーザーのサポート（新規ユーザーをサポートするには、既存のユーザーが最適であることが多い）。
• バグ報告
• 要件定義
• グラフィックやウェブデザインの提供
• プログラミング
• 使用例
• プロジェクトのインフラを支援する
• ドキュメント作成
• バグ修正
• 機能追加
• 建設的な意見を提供し、コミュニティの議論に参加する

コントリビューターは、GitHubやコミュニティ・フォーラムを通じてプロジェクトに参加します。コントリビューターはプルリクエストを通じてプロジェクトに変更を加え、それをコミュニティ全体がプロジェクトに取り入れるかどうか検討します。コミュニティ・フォーラムは、最初のコントリビューションを行う際に助けを求めるのに最も適切な場所です。

実際、コントリビューターの最も重要な役割の1つは、単にコミュニティの会話に参加することかもしれません。プロジェクトの方向性に関するほとんどの決定は、コンセンサスによって行われます。これについては、以下で詳しく説明します。しかし、一般的には、貢献者が（行動規範の範囲内で）自由に発言し、自分の意見や経験を述べることは、プロジェクトの健全性と方向性のために役立ち、合意形成の推進を助けることになります。

コントリビューターがプロジェクトで経験を積み、親しみを持つようになると、コミュニティ内での知名度やコミュニティへの貢献度が高まります。ある段階では、コア開発者チームに推薦されるかもしれません。

コア開発者

SCO傘下の各プロジェクトは、それぞれコア開発者のチームを持っています。彼らはそのプロジェクトの責任者です。

コア開発者とは?

コア開発者は、コミュニティとの継続的な関わりを通じて、プロジェクトの継続的な発展にコミットしていることを示したコミュニティのメンバーです。コア開発者になると、プロジェクトのリソースに直接アクセスできるようになるため、貢献者はより簡単にプロジェクトに関連した活動を行うことができるようになります。彼らは、フォークからのプルリクエストによって変更を提出することなく、プロジェクトのリポジトリに直接変更を加えることができます。

これは、コア開発者が自由に好きなことをできるという意味ではありません。実際、コア開発者はコントリビューター以上にパッケージの最終的なリリースに対して直接的な権限を持っていません。この栄誉は、プロジェクトの目的と目標を健全に尊重しているコミュニティの大切なメンバーであることを示していますが、彼らの仕事は、公式リリースに採用される前に、コミュニティによってレビューされ続けています。

コア開発者がプロジェクトでできることは？

プロジェクトによって、この役割の定義は若干異なるかもしれません。しかし、この呼称の一般的な使い方は、ある個人がコミュニティ内で信頼されるようになり、ある程度のコントロールを与えられるようになったというものです。これは、保護されていないブランチへのプッシュ権や、プルリクエストの承認に発言権を持つという形で実現されます。

プロジェクトでは、すべての貢献がコミュニティ全体によってレビューされることを保証するために、さまざまなコミュニケーションメカニズムを採用しています。これには、GitHubが提供するツールや、コミュニティフォーラムが含まれます。貢献者がコア開発者として招待されるまでに、ユーザーとして、そして貢献者として、さまざまなツールやワークフローに慣れておく必要があります。

コア開発者になるには?

コア開発者になるには、チームプレーヤーとしてプロジェクトに積極的に参加する意欲と能力があればよく、特別な要件はありません。

一般的に、コア開発者候補は、プロジェクトやその目的、戦略について理解していることを示す必要があります。また、一定期間にわたってプロジェクトに貴重な貢献をしてきたことも必要です。ただし、技術やその他のスキルの要件はありません。

新しいコア開発者は、既存のコア開発者によっていつでも推薦されることができます。少なくとも年に二回 (4月と10月)、運営評議会による投票が行われます。投票は秘密投票で行われるべきです。そのプロジェクトの既存の各コア開発者は、投票用紙に書かれた候補者の数に等しい数の票を受け取ります。例えば、候補者が四人いた場合、既存の各コア開発者は四票を持ちます。コア開発者はそれらの票を好きなように投じることができますが、 ひとつの候補者に複数回投票することはできません。候補者は、投票数 (投票資格のある人の数ではありません) の三分の二の承認を受けなければなりません。コア開発者が承認した後は、運営評議会がそのノミニーを承認し、最終決定する責任を負います。運営評議会は、ノミニーがコア開発者の称号を受けるに十分な功労があるかどうかを判断する権利を持ちません。しかし、コミュニティの健全性を保つために必要であれば、投票を無効とする権利を有します。

投票が行われた後、集計された投票結果はコミュニティフォーラムで公開されます。ノミニーは、自分に対する無効の説明について要求する権利を有します。コア開発者として認められなかったノミニーは、 将来再びされることができます。

コア開発者であることは、権利ではなく特権であることを認識することが重要です。その特権は獲得しなければならず、いったん獲得した特権は、極端な場合には運営評議会 (次のセクションを参照) によって削除されることがあります。しかし、通常の状況下では、コア開発者の肩書きは、その個人がプロジェクトやコミュニティとの関わりを続けたいと望む限り存在します。

特にプロジェクトの戦略的方向性や長期的健全性に関して平均以上の貢献度を示したコミッターは、運営評議会のメンバー、またはリリースマネージャに推薦されることがあります。この役割については後述します。

コア開発者の権利と責任は？

議論されているように、決定すべきことの大半は合意形成によるものです。ある問題がより論争的になった、または重大な決定を下す必要がある特定の状況では、リリースマネージャまたは運営評議会は、以下に詳しく説明するRFCプロセスの実施を決定する（または要求する）ことができます。

また、コミュニティの運営に発言力を持つことは、コア開発者の責務です。すべてのプロジェクトのすべてのコア開発者は、運営評議会のメンバーに推薦され、その選挙で投票することができます。

このポリシー (「SCOPE」) は、アクティブなコア開発者の3分の2の権限でのみ変更できます。ただし採択後6ヶ月間は、コア開発者はアクティブなコア開発者の単純多数の権限で変更する権利を留保します。

コア開発者が活動停止になった場合は？

すべてのコア開発者がプロジェクトに参加し、定期的に活動し続けることが望まれます。しかし、そのような約束が現実的でない、あるいは不可能な場合があることも理解されています。

したがって、運営評議会は参加を奨励する義務を負うとともに、参加する意思や能力がなくなったコア開発者を非活動状態にする責任を負います。この主な目的は、その人の行動を罰することではなく、アクティブであり続ける人のために開発プロセスを継続することを支援することです。

このため、「活動停止」したコア開発者はリポジトリへのコミット権を持たず、いかなる投票にも参加しないものとします。選挙の投票権を得るには、コア開発者は 前回予定されていたプロジェクトのリリースの時点で アクティブである必要があります。

活動停止中のメンバーは、いつでもその地位を復活させるよう運営評議会に要求でき、 その要求があれば運営評議会はそのコア開発者を再び活動可能にするものとします。

アクティブな状態を一定期間維持できないことが分かっている個人は、運営評議会と連絡を取り合い、必要に応じて非アクティブを宣言することが求められます。

「活動的な」コア開発者とは、過去六か月間に有意義な形で参加した人です。それ以上の定義は、運営評議会の裁量に委ねられます。

リリースマネージャー

コア開発者は、非保護ブランチへのコミットおよびマージを行うためのアクセス権のみを有するものとします。masterブランチおよびその他の保護されたブランチは、そのプロジェクトのリリース管理チームによって管理されます。リリース管理者は、コア開発チームによってコア開発チームから選出され、全リリースサイクルの間、その役割を果たすものとします。

各コア開発チームは、各リリースサイクルに対して何人のリリースマネージャを置くかを決定することができます。責任を分担し、一人に過度の負担を強いないために、1つのリリースサイクルには少なくとも2人のリリースマネージャがいることが強く推奨されます。しかし、マネージャーの数が多すぎて、彼らの努力が妨げられるようなことがあってはなりません。

リリース管理チームの主な職務は以下の通りです。

• 技術的な議論を監視し、促進することによって、開発サイクルを前進させる。
• リリースカレンダーを作成し、パッケージのリリースに必要なアクションを実行します。
• masterブランチおよびその他の保護されたブランチへのプルリクエストの承認
• masterブランチおよび他のprotectedブランチへのプルリクエストをマージします。

リリースマネージャーは、貢献の基準を満たし、コミュニティによって受け入れられたプルリクエストに対して、拒否権やマージを差し控える権限を持っていません。何が開発されるべきかを決めるのは彼らの責任ではなく、コミュニティの決定が実行され、プロジェクトが前進していることを確認するためのものです。

時には、コンセンサスで達成できない決定をする必要があるかもしれません。その場合、リリースマネージャーは、その決定をRFCプロセスに削除するよう求める権限を持っています。これは（後述するように必要な場合を除き）定期的に行われるべきではなく、より共同的な合意形成戦略を優先するため、この使用は控えるべきでしょう。

すべてのプロジェクトに同じ要件があるわけではないので、プロジェクトにおけるリリースマネージャに関する詳細は、本ポリシーの付録、またはプロジェクトの貢献ガイドラインに記載されるものとします。

必要に応じて、運営評議会は、職務を放棄したリリースマネージャを解任する権利、またはその他の正当な理由がある場合に解任する権利を有します。

運営協議会

運営評議会は、「プロジェクトオーナー」として特定され、SCOの資源と資産を管理する個人で構成される運営組織です。彼らの最終的な目標は、障害物を取り除き、必要に応じてメンバーを支援することによって、プロジェクトの円滑な運営を確保することです。また、コミュニティーの中で定期的に発言することが期待されています。

運営協議会は何ができる?

運営協議会のメンバーは、それぞれ他のコア開発者以上の権限を持たず、プロジェクトに関する決定、コミット、マージなどの追加的な権利を有さないものとします。

ただし、運営協議会は組織として以下のような能力を有しています。

• すべてのRFCの受理、差し戻し、および拒否
• コミュニティ行動規範の実施
• リポジトリ、サーバ、フォーラム、統合サービスなどのコミュニティ資産を管理する（または、そのような権限を他の誰かに委譲する）。
• 極端な場合、コア開発者の解任を含め、本ポリシーで認められている他のあらゆる強制的な手段を取ることができます。
• コミュニティ傘下のプロジェクトを採用または削除する

運営協議会は、可能な限りその権限を他の意欲的なコミュニティメンバーに委譲することが強く望まれます。

運営協議会は、本ポリシーを変更する権限を有しません。

運営協議会には何人いる?

4人です。

4票の委員会は、多数決を破る方法がなく、デッドロックに陥る可能性があるように思えますが、運営協議会はできるだけ投票をしないように推奨されています。その代わり、合意形成に努めるべきであり、議決が必要な場合は3名の同意票を必要とします。

運営協議会のメンバーは何年間在籍する?

1期は、1月から始まる暦年2年間とします。任期は、毎年、前年の審議会から継続する委員が2名となるようにずらされます。

従って、就任時の投票では、2年任期が2名、1年任期が2名の役職が用意されています。

任期に制限はなく、連続した任期を務めることも可能です。

運営協議会は誰が運営しているのか？

運営協議会が選出された後、グループ全体で議長として活動する1名を決定するものとします。議長は、運営協議会の他のメンバーに対する追加的な権利や権限を有しません。

議長の役割は、単に調整役および進行役です。議長は、すべてのガバナンス・プロセスが順守されていることを確認することが期待されます。この役職はより管理的、事務的なものであり、議長が議題を設定し、グループの議論を調整することが期待されます。

議員はどのように選出されるのですか？

年に一度、各プロジェクトの すべての適格なコア開発者 は、運営評議会のメンバーを選出する権利があります。

指名は 9 月 1 日から始まり、9 月 30 日に締め切られます。その後、投票は 10 月 1 日から始まり 10 月 31 日に締め切られます。その年の Sanic フレームワークの 6 月のリリース日にアクティブなすべてのコア開発者は、運営評議会の空席につき 1 票を得る資格を得ます。明確にするために、投票資格を得るために、コア開発者は Sanic フレームワークのコア開発者である必要はなく、むしろその日にそれぞれのプロジェクトで活動している必要があります。

投票のトップ受信者は、勝者として宣言されるものとします。もし同点であれば、ランダムに決定される前に、同点の候補者自身が論争を解決することが強く推奨されます。

運営協議会の設立投票については、上位2名の得票者が2年間、次の2名の得票者が1年間の任期で就任するものとします。

運営評議会の候補者となるには、過去12ヶ月間、少なくとも一つのプロジェクトにおいてコア開発者として活動していなければなりません。

欠員が出た場合は？

任期中に運営協議会に欠員が出た場合は、前回の選挙で次に得票数の多かった者が残りの任期を務めることを申し出るべきです。この方法で空席を埋めることができない場合、運営協議会はその空席を埋めるための最も適切な方法（任命、投票、その他の方法のいずれか）を決定することができます。

運営協議会のメンバーが活動しなくなった場合、その人物は直ちに運営協議会から外され、その席は空席となります。

極端な場合には、すべてのコア開発者の団体は、 投票権を持つコア開発者全員の三分の二以上の賛成により、 理由があって運営協議会のメンバーを解任する投票を起こす権利を持ちます。

運営協議会はどのように業務を遂行する？

運営協議会は、できる限りオープンに事業や議論を行います。コミュニティーのメンバーであれば、誰でもその会話に加わることができるようにします。しかし、時には非公開で議論を行うことが必要または適切である場合もあります。会話のための適切な場を選択することは、議長の管理業務の一部です。

運営方法の詳細は本方針の範囲外ですが、運営審議会は、少なくとも四半期に一度、「リアルタイムの」話し合いの場を持つよう努めることが推奨されます。これは、ビデオ会議、ライブチャット、またはその他の適切な手段で実現できます。

サポート

コミュニティの参加者は全員、プロジェクト管理インフラ内のユーザーをサポートすることが推奨されています。このサポートは、コミュニティを成長させる方法として提供されます。サポートを求める人は、プロジェクト内のすべてのサポート活動は自発的なものであり、したがって時間の許す限り提供されるものであることを認識する必要があります。保証された応答時間や結果を必要とするユーザは、コミュニティのメンバーからサポート契約を購入する必要があります。しかし、このプロジェクトに参加し、他のユーザーをサポートすることを望むユーザーにとっては、コミュニティのサポートチャネルは理想的です。

意思決定プロセス

プロジェクトの将来についての決定は、最も新しいユーザーから最も経験豊かなメンバーまで、コミュニティのすべてのメンバーとの議論を通じて行われます。誰もが声を上げることができるのです。

プロジェクト管理に関する機密性のない議論は、すべてコミュニティフォーラムやその他の指定されたチャンネルで行われます。時折、機密性の高い議論が非公開で行われることもあります。

プロジェクトが終わりのない議論や継続的な投票によって停滞しないように、プロジェクトはレイジーコンセンサスというポリシーを運用しています。これにより、正式な投票に頼ることなく、大部分の決定を行うことができます。重要な決定事項 (以下に定義) については、別途 Request for Comment (RFC) プロセスがあります。

技術的意思決定

プルリクエストと技術的な決定は、一般的に以下のカテゴリーに分類されるべきです。

• Routine: ドキュメントの修正、クリーンアップや追加テストのためのコード変更。機能的な変更はありません。
• Minor: コードベースへの変更は、バグを修正するか、または些細な機能を導入する。破壊的な変更はありません。
• Major。既存のAPIを破壊または非推奨とする、自明ではない方法で操作を変更する、または重要な機能を追加するコードベースへの変更。

一般に、リポジトリへの変更がマージ前に適切な承認を受けるようにすることは、リリースマネージャの責任です。

リリースマネージャーは、コード品質の基準を満たす定型的な決定について、追加的な情報なしに個別にレビューし、承認する権限を保持します。

レイジーコンセンサス

意思決定（コミュニティまたは運営協議会のいずれによるものであっても）には、通常、以下のステップが含まれます。

• 提案
• 議論
• 投票（議論しても意見がまとまらない場合）
• 決定

コミュニティメンバーは誰でも、コミュニティで検討するための提案を行うことができます。新しいアイデアについて議論を始めるには、コミュニティフォーラムの適切なチャンネルにメッセージを投稿するか、GitHub にそのアイデアを実装したプルリクエストを送信してください。これにより、そのアイデアのレビューが行われ、必要であれば議論が行われます。

このレビューとディスカッションの目的は、コントリビューションに対する承認を得ることです。プロジェクトコミュニティのほとんどの人はビジョンを共有しているので、合意に達するための議論はほとんど必要ないことが多いです。

一般に、誰も明確に反対しない限り、その提案やパッチはコミュニティの支持を得たものとして認識されます。これはレイジーコンセンサスと呼ばれるもので、つまり、明確に意見を述べなかった人は、暗黙のうちにその提案の実現に同意していることになるのです。

レイジーコンセンサスは、SCOの中で非常に重要な概念です。ある提案に異論がない人が自分の立場を表明するのに時間をかける必要がなく、他の人もそのようなメッセージを読むのに時間をかける必要がないため、このプロセスによって大勢の人が効率よく合意に達することができるのです。

ダラダラとした合意形成を効果的に行うためには、その提案に異論がないと判断するまでに適切な時間を置く必要があリマス。これは状況によって多少異なりますが、一般的には72時間が妥当であると考えられています。この要件により、誰もが提案を読み、咀嚼し、反応するための十分な時間が与えられます。この期間は、場所や時間の制約に関係なく、すべての参加者ができるだけ参加できるように選択されます。議論の進行役（議長であれ、リリースマネージャであれ、該当する場合）は、このような合意形成のための適切な時間の長さを決定する責任を負うものとします。

いわゆる定型的な決定に関して前に書いたように、リリースマネージャはより短い時間内に決定を下す権利を持ちます。このような場合、怠惰な合意は黙示されるものとします。

コメント要求（RFC）

運営協議会は、RFCのプロセスを監督する責任を負います。このプロセスは、コミュニティの全メンバーに対して開かれた議論を維持し、提案を検討する十分な時間、メンバーが返答し、有意義な議論を行うための時間を確保します。

最終的な決定は運営協議会に委ねられます。しかし、コミュニティ内に存在するコンセンサスに反する決定を運営協議会が採択することは、強く推奨されません。コンセンサスとプロジェクト全体およびコミュニティの目標との間に矛盾がある場合、時折このようなことが起こるかもしれません。

RFCは、運営評議会が定める公開の方法で運営評議会に提出することにより開始されます。議論は、一般的には運営協議会、特に議長によって継続され、促進されます。

運営協議会が適切と考える状況においては、RFCのプロセスを放棄し、怠惰な合意を優先させることができます。