各プロジェクト管理委員会（PMC）は、ソフトウェア製品のリリースを投票で決定し、新しいPMCメンバーとコミッターをアパッチプロジェクトに選出します。
PMCはASFで最も重要な組織です。これらのグループが、プロジェクトがリリースするソフトウェアを決定し、ASFの実際の作業の大部分を行っています。
このドキュメントは、ASFの組織がどのように、なぜそのようなやり方で機能するのかについての背景情報です。公式のポリシー情報や「ハウツー」スタイルのガイドについては、参考文献または/devにあるドキュメントを参照してください。
目次
特定のアパッチプロジェクト内でPMCに選出されたコミッターは、ASFを代表してプロジェクトの監督を行い、プロジェクトのリリース戦略を決定します。PMCメンバーは個人として行動し、PMCまたは開発リストで行動するときは、プロジェクトの最善の利益のために決定を下すことが期待されます。
各プロジェクトのPMCは独立しています。PMCは、プロジェクトのコミュニティおよび技術的な方向性を自由に設定でき、リリースとコミュニティの健全な発展を監督する責任を直接負います。PMCは、ASFの理事会または他の役員によって設定された特定のコア要件をプロジェクトが確実に満たすようにする責任があります。たとえば、法律、ブランディング、インフラストラクチャ関連の要件に従い、コミュニティがアパッチウェイの基本アウトライン内で活動していることを確認します。
PMCメンバーは、新しいコントリビューターをプロジェクトにコミッターまたはPMCメンバーとして指名し、新しいコミッターまたはPMCメンバーを選出するかどうかを投票します。PMCメンバーは、プロジェクトの問題について拘束力のある投票権も持っています。
PMCには、少なくとも3人のアクティブメンバーが必要です。これは、製品リリースに必要な肯定的な（+1）票の最小数が3つであるためです。
理事会は、月例会議での決議により、特定の名前付きプロジェクトを管理するPMCを作成します。新しいトップレベルプロジェクト（TLP）は、インキュベーションからの正常な卒業投票の後、アパッチインキュベーターのポッドリングから作成されることが最も一般的です。理事会は、プロジェクトのPMCの議長を務めるために、副社長（会社の役員）を任命します。
PMC議長は、他のPMCメンバーと同様に、プロジェクトの問題について1票を持つ通常のPMCメンバーとして機能します。PMC議長の主な義務は、プロジェクトの健全性とステータスに関する四半期ごとのレポートを理事会に提供することです。PMC議長は、board@メーリングリストを購読し、プロジェクトに関する理事会の懸念事項を認識し、理事会の懸念事項に対処するためにPMC全体と協力する責任があります。
PMC議長は、新しいメンバーがPMCに追加されたときに、公式のPMC名簿を更新する責任も負います。 新しいPMCメンバーを追加する方法を参照してください。プロジェクトに関与しなくなったPMCメンバーは、PMCからの辞任を要求することもできます。
PMC議長/VPの変更には、ASFの役員の任命が含まれるため、月例会議で承認される理事会決議が必要です。PMC議長変更プロセスに従ってください。
ASFの公式委員会として、PMCはプロジェクトの運営とリリースの法的監督を行い、ソフトウェアリリースが個々の開発者ではなく、ASFの組織としての行為として行われるようにします。これにより、個々のコミッターではなく、組織としてのASFがアパッチプロジェクトの製品に対する法的責任を負うことが保証されます。すべてのPMC議長は理事会に四半期ごとのレポートを提供し、これにより理事会がすべてのASFプロジェクトを監督できるようになります。
すべてのPMCメンバーは、プロジェクトのprivate@リストを購読する必要があり、少なくともプロジェクトの運営を認識するためにdev@リストを購読する必要があります。
事実上すべてのPMCのコミュニケーションは、dev@リストまたはその他の適切な公開メーリングリストで行われる必要があります。各PMCのprivate@リストは、人事問題、新しいコミッターまたはPMCメンバーを招待するかどうか、まだ公開されていないセキュリティ関連の問題など、機密性を必要とする問題に使用されます。プロジェクトの将来に関するPMCの議論が公開されているdev@リストで行われるようにすることで、コミッターではない人も含めて、コミュニティ全体が議論を追跡し、問題についてコメントできるようにします。PMCメンバーまたはコミッターのみがプロジェクトの問題について拘束力のある投票権を持っていますが、健全なPMCはプロジェクトのより大きなコミュニティと積極的に協力します。
PMCは、通常のプロジェクトメーリングリストに加えて、JIRA/Bugzilla、wiki、および公開ビューとコメントを提供するその他のインフラストラクチャでホストされているツールを自由に使用できます。PMCは、プロジェクトが望むサービスについてインフラストラクチャチームに具体的なリクエストを行う必要があります。
一部のPMCは、プロジェクトのアイデアをブレインストーミングするために、対面での会議、電話会議、またはIRCチャットを主催しますが、さらなる議論と最終的な決定を行うために、すべての情報をプロジェクトの公開リストに戻す必要があります。多くのPMCは、エンドユーザー教育と技術情報の共有に焦点を当てた、技術分野の貢献者または組織が主催する、ミートアップ、バーキャンプ、またはその他の対面イベントを直接組織するか、または開催します。
プロジェクトの分散性とボランティアの性質を考えると、PMCの対面会議は非常にまれです。すべてのプロジェクトビジネスは、プロジェクトの通常の公開メーリングリストで行われます。
PMCは、アパッチウェイのように、意思決定が共同で行われる限り、プロジェクト内のメリットの基準を自由に設定できます。健全なPMCは、コミッターではない人からの貢献（特定のコードパッチ、報告またはコメントされたバグ、またはプロジェクトリストでの役立つ対話）を定期的にレビューして、コントリビューターを潜在的なコミッターとして評価します。PMCメンバーがプロジェクトに役立つ新しいコントリビューターを指導することで、プロジェクトコミュニティが強化されます。
PMCは、コミッターシップまたはPMCへのメンバーシップを検討するためにコントリビューターに期待するコミットメントと作業のレベルが大きく異なります。一部のPMCは、既存のコミッターから新しいPMCメンバーを投票で選出します（つまり、進歩はコントリビューター->投票->コミッター->投票-> PMCです）。一方、他のPMCは、常に新しいコミッターをPMCに同時に選出します（コントリビューター->投票->コミッターとPMCメンバー）。PMCは、投票を管理し、新しいコミッターにコミット権限を付与する責任を単独で負います。ただし、理事会は、新しく選出されたPMCメンバーを、PMCの正式なメンバーになる前に承認する必要があります（上記の法律セクションで説明したように）。
1つのPMC内のメリットは、他のPMCには譲渡できません。各プロジェクトのPMCは、プロジェクトのコミッターリストを個別に管理します。1つのプロジェクトで長い歴史を持つPMCメンバーまたはコミッターは、他のプロジェクトのPMCメンバーによる過去の活動によって知られていることがよくありますが、コミッターになりたい個別のプロジェクトごとにメリットを構築することが期待されます。他のPMCと密接に連携し、それに応じて人員の重複が大きいPMCは多数ありますが、各PMCのメリットは独立しています。
「コミッター」という言葉のplain senseは「ソースリポジトリで新しいリビジョンを作成できる人」ですが、コミッターシップの概念は社会的なものです。つまり、PMCがコミッターになるように招待し、招待を受け入れた人がコミッターです。
PMCメンバーのみがプロジェクトリリースについて拘束力のある投票権を持っていますが、一般的にPMCメンバーは、プロジェクトコミッターおよびdev@リスト上のコントリビューターと平等に参加します。PMCメンバーは、プロジェクトのメーリングリストが新規参入者を歓迎し、メンバーがメーリングリストでコミュニティ標準を推進および遵守することで、健全で多様なプロジェクトコミュニティを育成することができます。
コミュニティが重複するプロジェクトは多数あり、そのため一部の個人的または技術的な関係が共有されていますが、基本的に各プロジェクトはプロジェクト作業の大部分に関して独自のコミュニティです。すべてのプロジェクトはASF全体の一部であり、特定の基本要件とアパッチウェイの一部を共有していますが、すべての技術的な方向性とほとんどのコミュニティの焦点は個々のプロジェクト内にあります。
PMCは、プロジェクトのコミュニティの健全性と多様性について理事会に報告します。PMCメンバーの構成（PMCの個人の雇用または所属）に関する厳格な要件はありませんが、理事会はPMCが外部の商業的影響から独立して運営することを期待しています。理事会は、コミュニティ全体の代わりに活動することを確約できない、または特定の商業的利益のために活動するPMCに連絡し、修正を要求します。
理事会は、プロジェクトや活動の技術的な方向性を提供しません。PMCはプロジェクトの統治機関であり、外部の商業的影響から独立して、プロジェクトコミュニティ全体の最善の利益のためにプロジェクトの技術を管理することが期待されています。
これは驚きに思う方もいるかもしれませんが、ASFがそのプロジェクトに最大限の自由を保証するように意図的に構成されていることを示す重要な反映です。理事会とASFは、Apache Wayに従う意思のあるソフトウェアプロジェクトコミュニティに、その活動の場を提供できることを嬉しく思っています。ASFの使命は、共通の利益のためにソフトウェアを提供することです。私たちは、同じ志を持つコミュニティがそのソフトウェアを提供することを支援できることを嬉しく思い、有用なソフトウェアを中心にコミュニティが形成されることを確信しており、効果的かつ協調的にソフトウェアを構築する方法はたくさんあることを理解しています。