メインコンテンツへスキップ
The Apache Software Foundation
Apache 20th Anniversary Logo

プロジェクト管理委員会ガイド

このガイドでは、プロジェクトを管理する際のプロジェクト管理委員会(PMC)メンバーの一般的な責任と、日常的なメンテナンスのための一般的な手順について概説します。PMCの目的と理由に関する概要については、PMCガバナンスの概要をご覧ください。

目次

対象読者

このドキュメントは、ASFプロジェクトのPMCメンバーを対象としています。PMCは、Apacheプロジェクトの適切な管理と監督の責任を負い、年4回理事会に直接報告します。すべてのPMCには議長がおり、その議長は「Apacheプロジェクト名担当副社長」という役職を持つASFの役員でもあります。

PMCとは?

プロジェクト管理委員会(PMC)は、Apacheソフトウェア財団の委員会であり、そのトップレベルのプロジェクトに対する責任とガバナンスを担っています。PMCは、開発者に意思決定権と監督責任を委譲するための手段です。

プロジェクトのコミッターはコードを更新する権限を持っていますが、プロジェクトのソフトウェアの正式リリースについて投票する権限を持つのは、団体としてのPMCのみです。PMCはまた、プロジェクトに新しいコミッターやPMCメンバーを投票で決定したり、このドキュメントで概説されている他のポリシーに従ったりする責任も負っています。

PMCに必要なポリシー

このセクションの用語は、RFC2119に従って使用されています。理事会は、すべてのPMCがこれらのポリシーを理解し、遵守することを期待しています。

プロジェクトの状況を四半期ごとまたは要求に応じて報告する

PMC議長/副社長は、四半期ごと、または取締役から要求された場合に、プロジェクトの健全性に関するレポートを理事会に提出しなければなりません。PMC議長が不在の場合、または議長の指示により、他のPMCメンバーがレポートを作成して提出することができます。

同様に、PMC議長は、PMCレポートまたはその他のプロジェクト運営に関する理事会の質問に対して、board@メーリングリストに回答し、理事会が必要とする措置をPMCが講じることを保証しなければなりません

PMC議長/副社長は、以下にリストされている特定の追加義務を負っています。

PMCは、プロジェクトでの作業と作成するコードが、Apache Licenseの適切な使用、IPおよび著作権の適切な処理、暗号化の処理、および製品の公式ソフトウェアリリースの作成など、関連する法務委員会のポリシーを遵守していることを保証しなければなりません

ブランド管理ポリシーを遵守する

PMCは、プロジェクトのブランドを管理し、PMCのブランディング責任とプロジェクトWebサイトに関するApacheプロジェクトのブランディング要件の概要で定義されているように、すべてのApache®マークを適切に扱うことを保証しなければなりません

Apacheブランドの誤用を責任を持って報告する

PMCは、第三者によるApacheプロジェクトブランドの使用をレビューし、適切な場合はApache商標使用報告ガイドラインに従わなければなりません

パブリックメーリングリストでプロジェクトビジネスを行う

すべての技術的な決定とPMCの作業の大部分は、dev@やuser@などの通常のパブリックメーリングリストで行う必要があります。決定は、IRC、Slackチャンネル、会議での対面など、他のメディアで行われてはなりません。プロジェクトメンバーは、そのような設定から生じた提案を、すべての参加者が議論して決定するために、適切なメーリングリストに戻す必要があります。

PMCは、意思決定プロセスで、さまざまなタイムゾーンのプロジェクト参加者が意思決定に参加する機会を得られるように、十分な時間(通常は少なくとも72時間)をかけて入力を許可する必要があります

プロジェクトのプライベートメーリングリストを監視する

PMCメンバーは、プロジェクトのプライベートメーリングリストを購読しなければならず、十分な数のメンバーがそれを監視して、理事会から送信されるロールコールやその他のリクエストにPMCが対応できるようにしなければなりません

プライベートメーリングリストでのプロジェクトビジネスを制限する

すべてのPMCは、プライベートメーリングリストでのコミュニケーションを、パブリックで議論できない問題のみ制限しなければなりません。以下のような議論が含まれます。

すべてのプロジェクトは、このプライベートリストにprivate@*project*.apache.orgという名前を使用しなければなりません(ここで、*project*はプロジェクトの名前です)。PMCメンバーは、プライベートにアーカイブされたメーリングリストのメッセージの機密性を維持する必要があります。

PMC議長の職務の遂行方法

PMCと議長の定義を参照し、ASFの定款をよく理解してください。新しいPMC議長へのアドバイスには、さらに役立つ情報が記載されています。

プロジェクトに関する理事会議事録を確認する

PMC議長は、理事会の会議議事録で自分のプロジェクトに関連する項目、特に取締役がプロジェクトレポートについて行ったコメントを監視し、関連情報をプロジェクトPMCに伝え、それ以外の場合は理事会とPMC間の質問のパイプ役を務める必要があります。

注:理事会からのフィードバックと理事会会議の未編集の議事録は、通常、公開情報ではなく、機密として扱う必要があります。理事会が会議の議事録を正式に承認した(通常は翌月)後にのみ、議事録が公に公開されます。会議議事録に関するフィードバックは通常、private@リストに送信されます。

プロジェクトの四半期ごとの理事会レポートが提出されていることを確認する

PMC議長は、四半期ごとの理事会レポートを個人的に作成する必要はありませんが、レポートが完全であり、時間どおりに提出されていることを確認する責任があります。

どの委員会でもそうであるように、議長はファシリテーターであり、PMC内での役割は、誰もが発言する機会を得られるようにし、会議やメーリングリストがスムーズに流れるようにすることです。うまく運営されているPMCは、協力して理事会レポートの情報をまとめますが、議長は特にそれを理事会に届ける責任があります。Apache Wayには「リーダー」という概念はありません。

新しいコミッターのリクエストが作成されていることを確認する

プロジェクトで新しいコミッターが選出され、アカウントを作成するプロセスが完了した後、PMC議長は、新しいコミッターがプロジェクトリポジトリへのカルマ(アクセス権)を持っていることを確認します。

PMC名簿に関するASF記録を維持する

議長は、committee-info.txtにあるPMCの公式名簿を、PMCメンバーについて常に最新の状態に保つ責任があります。新しいPMCメンバーを追加する方法を参照してください。

PMCメンバーを追加するときにNOTICEを送信し、フォローアップする

理事会へのNOTICEメールは、名簿が更新されると自動的に生成されるようになりました。PMCが名簿を更新する前にNOTICEを送信する必要はありません。招待が受け入れられたらすぐに名簿を更新できます。

必要に応じてboard@メーリングリストを購読する

PMCの議長は、プロジェクトに影響を与える可能性のある財団レベルの問題を常に把握するために、board@ メーリングリストを購読することを歓迎します。これは以前は必須でしたが、理事会は2020年6月に任意としました。board@ は非公開でアーカイブされるメーリングリストであるため、board@からの情報を他の場所に転送してはなりません

PMCの議長を変更する方法

PMCがVP/議長を変更したい場合、通常はPMC内で投票を行うか、新しい議長を誰にするかについて合意に達します。その後、PMCのメンバーは、この変更が正式に行われる前に、次の月例理事会で承認(または却下)されるための正式な決議を board@ に送信できます。

次回の理事会に正式な議長変更決議を提出するには、Whimsy理事会アジェンダ(Apacheログインが必要です)を使用します。理事会アジェンダにログインし、下部にある「項目を追加」ボタンをクリックして、適切な決議を追加します。PMCメンバーがWhimsyにログインできない場合は、board@ メーリングリストに連絡して支援を求めてください。

理事会が決議を承認すると(通常は翌月の会議で)、新しく任命されたプロジェクトVPおよび議長は、新しい役割を受け入れる方法に関する指示を受け取ります。

PMC議長はASFの役員またはメンバーですか?

はい、彼らは企業の役員であり、必ずしも「メンバー」ではありません。PMC議長は、最上位プロジェクトの副社長であり、プロジェクト管理委員会の議長を務めるために理事会によって任命されます。PMC議長が企業の法的役員である理由の説明を読む

PMC議長/VPは必ずしもASFのメンバーではありません。PMCのメンバーと議長/VPは、プロジェクト内で功績を認められますが、これはASF全体の財団のガバナンスとは異なります。財団のメンバーは、本質的に、数百のソフトウェアプロジェクトをホストする法人の株主です。

プロジェクトのレポートに対する理事会のフィードバックに返信する手順

理事会は毎月の会議で提出されたすべてのプロジェクトレポートを読み、時には個々の取締役が会議アジェンダのWhimsyツールを使用してコメントをしたり質問をしたりします。毎月の会議の直後、秘書はWhimsyを使用して、すべてのコメントを各プロジェクトの private@ メーリングリストとPMC議長に直接自動的に送信します。

コメントには、レポートに関する簡単なフィードバックやメモなどがあります。また、一部のコメントは、取締役からの具体的な質問です。このメールに質問や異常なフィードバックがある場合、理事会はPMCメンバーが board@ に全員返信することを期待しています。

プロジェクトが「Attic」に移行する理由

そのホームページで説明されているように、「Attic」は*そうでなければ監督されないプロジェクトの監督を提供することを目的としています*。

ASFプロジェクトが成熟して静かであり、開発活動がほとんど行われていなくても問題ありません。それ自体は「Attic」に移行する理由にはなりません。

ただし、存続可能なASFプロジェクトであるためには、プロジェクトを監督するのに十分な活動的なPMCメンバーが必要です。たとえば、コードを修正およびリリースし、セキュリティの脆弱性やその他の重大なバグを処理します。

PMCは受信したすべてのバグやリクエストを修正する必要はありませんが、理事会は、少なくとも3人のPMCメンバーがプロジェクトのメーリングリストを監視しており、このような場合に返信して対応できることを確認できる必要があります。

この目的のために、理事会はPMCロールコールを実施することがあります。

場合によっては、プロジェクトを離れるメンバーの数が減り、3人未満のPMCメンバーしか残らない一方で、他のコミュニティメンバーがプロジェクトの保守を継続することを希望する場合があります。このような場合、可能な限り最善の方法は、それらのコミュニティメンバーの数人をPMCに選出して、プロジェクトを存続させることです。

それが実現しない場合、理事会は、新しいまたは修正されたPMCで再確立することにより、PMCを「再起動」できます。例として、2019年2月の理事会議事録からのApache Xalan PMCを再起動するための理事会決議を参照してください。

成熟したプロジェクトや非常にゆっくりと実行されているプロジェクトは、定期的に(年に1回推奨)PMCロールコールを実施して、その存続可能性を確認する必要があります。

要約すると、プロジェクトが「Attic」に移行する唯一の理由は、活動的なPMCメンバーの数が不足していることによる監督不足です。

「Attic」に移行することは必ずしも悪いことではないことに注意してください。それは、プロジェクトを管理するためのアクティブなコミュニティが現在存在しないという単なる反映です。また、プロジェクトのコードのユーザーに対して正しい期待を設定するための明確な方法でもあります。

PMCロールコールを実行する方法

理事会は、定期的にレポートを提出しない、メーリングリストまたはリリースでの活動が非常に少ない、またはセキュリティ問題に対応していないと思われるプロジェクトに対して、ロールコールを求めることがあります。

取締役(理事会を代表して)がPMCにロールコールを実行するように依頼した場合、PMCは、少なくとも3人のPMCメンバーが活動していることをメールスレッドで示すことで、必ず応答する必要があります。

PMCは、活動中の各メンバーが board@ へのスレッドに返信するか、1人のPMCメンバーが、少なくとも3人のPMCメンバーがプロジェクトを監視しており、必要に応じて新しいリリースの作成を支援できると返信したPMCのリストのスレッドへのリンクを送信することで、これを行うことができます。少なくとも3人のPMCメンバーが応答したら、必ず board@ メーリングリストに知らせてください(または常にcc:board@)。

プロジェクトは、理事会のロールコール要求に必ず返信する必要があります。次の月例理事会までに、少なくとも3人のPMCメンバーが存在することを示すことができない場合、理事会は、プロジェクトが閉鎖され、監督不足のためにApache Atticに移行すると結論付ける可能性があります。

上記の「プロジェクトが「Attic」に移行する理由」も参照してください。

PMCメンバーシップ管理

PMCメンバーを追加する方法

PMCにメンバーを追加する通常の手順は次のとおりです。

ただし、必要な投票数に達するのを妨げる低いPMC参加率や、PMC議長が長期間不在の場合など、特定のケースでは、PMCメンバーはPMC投票を成功させなくても理事会にPMCに必要な変更を求めることができます。このような場合、理事会はPMC内で反対がある場合にのみ懸念します。

その人をPMCに招待する

候補者を正式にPMCに追加するには、以下を行う必要があります。

公式PMC名簿を更新する

注:招待される人がまだASFコミッターでない場合は、まずその人のコミッターアカウントをリクエストしてください。公式PMC名簿の更新は、Whimsyツールを使用して行うことができます。

https://whimsy.apache.org/roster/committee/

PMCのページをクリックして、追加/変更の手順に従います。Whimsyツールが機能しない場合は、LDAPの更新とcommittee-info.txtの更新に関するドキュメントを参照してください。

PMCメンバーを削除する方法

PMCを辞任する方法

PMCを辞任したい場合は、プロジェクト(通常はprivate@リスト)に正式に辞任するメールを送信し、PMC議長に名簿から削除するように依頼してください。PMC議長は、以下の(削除手順)[#emeritus]に従うことができます。

「PMCのメンバーの辞任は、財団のメーリングリストアーカイブに記録された辞任の受領時に直ちに効力を発するものとし、受領後72時間以内にそのメンバーが取り消すことができます。」

公式の手順は、2022年9月の理事会議事録セクション7 C. PMCメンバーシップ変更プロセスにあります。

PMCメンバーを辞任または名誉職としてマークする方法

ASFには、「名誉PMCメンバー」という正式な概念はありません。個人はPMCのメンバーであるか、そうでないかのいずれかです。プロジェクトは、非アクティブだがPMCに残っているPMCのメンバー、または以前PMCに所属していて辞任したメンバーを指定するための独自のポリシーを自由に設定できます。一部のプロジェクトでは、以前のPMCメンバーがプライベートPMCリストに残ることを許可したり、PMCメンバーが単に要求するだけで復帰を許可したりするためのガイドラインも確立しています(復帰には標準の理事会通知手順に従う必要があることに注意してください)。

PMCメンバーの辞任が財団のメーリングリストで受理されると、辞任は有効と見なされます。ただし、PMCメンバーは辞任を取り下げるために72時間の猶予があります。理事会への通知は必須ではありませんが、追跡を容易にするために推奨されます。

辞任が有効になったら、PMC議長は次のことを行う必要があります。

PMCは非アクティブなメンバーを削除すべきか?

プロジェクトは、一貫して適用する限り、非アクティブなメンバーの扱いに関する独自のポリシーを確立できます。非アクティブになったPMCメンバーを保持することは問題ありません。また、彼らが再びアクティブになることを選択した場合、プロジェクトとの連絡を維持しやすくすることができます。

多くの場合、参加できなくなったPMCメンバーは、リクエストをメールで送信することにより、PMCを辞任します。PMCに多数の非アクティブなメンバーがいる場合、PMCは非アクティブなメンバーに辞任を希望するかどうかを尋ねることがあります。

PMCメンバーを一方的に削除する方法

PMCがメンバーの1人を(そのメンバーの要求または同意なしに削除することを選択した場合、PMCは理事会にメンバーの削除を依頼する必要があります。PMCチェアは、削除要求とPMCがその削除を正当化する理由の詳細を記載したメールをboard@メーリングリストに送信し、プロジェクトのprivate@リストをコピーする必要があります。理事会は、削除が論争の的になるか反対されているかどうかを確認するために、要求とプロジェクトのメーリングリストを確認し、通常は翌月の理事会で決定を行います。

コミッターまたはPMCメンバーが亡くなった場合の対処法

これは悲劇的な出来事ですが、財団には非常に多くのコミュニティがあるため、時々発生するのは避けられません。各コミュニティは、この問題をどのように処理するかを決定できます。

プロジェクトコミッターの管理

新しいプロジェクトコミッターを招待する方法

プロジェクトのPMCは、プロジェクトへの貢献度の高い貢献者を検討し、それらの貢献者をコミッターとして推薦し、コミッターとして(場合によってはPMCメンバーとしても)投票で承認する責任があります。PMCは、新しいコミッターが適切なリソースとASFドキュメント(例:新しいコミッター向けのガイドコミッターFAQ)にアクセスできるように、新しいコミッターを指導する必要があります。生産的な個人がすでに別のプロジェクトでApacheコミッターである場合、プロジェクトへのカルマを付与するだけで済みます。

新しいコミッターアカウントのリクエストを送信する方法

ほとんどのPMCは、コミッター候補者を招待するかどうかを決定するために、正式な投票を実施しますが、新しいコミッターを追加することについて合意を得るための独自の文書化されたプロセスに従うことができます。

PMCが正式に個人をコミッターとして招待したい場合、その人を招待し(これらの適切なテンプレートのいずれかを使用して)、新しいコミッター(コミッターのICLAがまだファイルにない場合)に、個人の貢献者ライセンス契約(ICLA)を事務局に提出することを要求します。事務局は、ASF事務局または理事メンバーによって承認されたCLAを受け取らない限り、新しいコミッターアカウントを処理できません。PMCは、新しいコミッターと協力して、CLAが適切に受信および記録されるようにする必要があるため、foundation/officersリポジトリのファイルiclas.txtを監視する必要があります。ASFメンバーと役員(PMCチェア)のみがアクセスできます。Apache電話帳には、iclas.txtファイルから毎日生成される未登録CLAページがあり、最近受信したCLAがそこに表示されます。

新しいコミッターに、提出されたICLAにPMC名と希望のアカウントIDの両方を含めるように勧めてください。これらの情報が両方ともICLAフォームに記載されている場合、ICLAは正しいアドレス(secretary@apache.org)に送信され、事務局または事務局補佐が新しいコミッターの[VOTE][RESULT]を確認できれば、アカウントはICLAを提出する人(事務局または事務局補佐)によってリクエストされます。

新しいアカウント情報がICLAに記載されていない場合、PMCチェアは新しいコミッターの希望するアカウントIDを取得し、新しいアカウントをリクエストする責任があります。

ICLAが提出されたら、ASF新規アカウントリクエストフォームを使用してリクエストを生成します。PMCチェアが何らかの理由で利用できない場合、ASFメンバーは代わりに代理を務めることができます。

インキュベート中のプロジェクトの場合:もし

事務局または事務局補佐がアカウントをリクエストします。それ以外の場合、メンターがアカウントをリクエストします。アカウントをリクエストするポッドリングがポッドリングのドロップダウンリストに表示されない場合は、フリーテキスト入力ボックスにポッドリング名を入力してください。

ほとんどのPMCは、プライベートメーリングリストでの選挙プロセスを通じて、新しいコミッターを決定します。Apache Mail Archivesを使用して、最終投票集計へのURLまたはメッセージID参照を含めてください。

新しいアカウントのリクエストは、PMCチェアとASFメンバーからのみ受け付けられます。インキュベーションが承認されたプロジェクトの代理として行動する場合は、スポンサーのPMCに連絡して、新しいアカウントのリクエストを処理してもらうようにしてください。

リクエストはPMCメーリングリストにCCされます。PMCからの異議がなければ、インフラストラクチャチームがアカウントを作成し、適切なグループ権限を割り当てます。これには数日かかる場合があります。新しいアカウントを確認するメッセージがPMCメーリングリストと新しいコミッターに送信されます。

ICLAにPMC名が含まれている場合、通常、アカウントはプロジェクトのソースリポジトリへのアクセスを許可する正しいLDAPグループにすでに設定されています。

そうでない場合、PMCが引き継ぎ、残りのインフラストラクチャニーズを提供します。特に、PMCチェアには、プロジェクトのソースリポジトリへの書き込みアクセスを提供する能力と責任があります。

プロジェクトソースリポジトリへのSVNアクセス(カルマ)を付与する方法

ほとんどの操作では、PMCは新しいコミッターにSVNアクセスを許可するために何もする必要はありません。ただし、自動LDAPプロセスが何らかの理由で機能しない場合は、PMCはASF承認テンプレートを使用できます。

ファイルの[groups]セクションは、SVNグループ名とそのメンバーを定義します。グループはLDAP参照として定義されています。それらを更新する方法については、以下を参照してください。

SVNでディレクトリへのアクセスを許可または拒否するには、PMCチェアは適切な[group]エントリを更新する必要があります。PMCチェアは、LDAPに保持されているプロジェクトグループを変更するアクセス権を持っています。

Whimsy Rosterを使用したLDAPグループメンバーシップの更新

PMCチェアは、Whimsy rosterツールを使用して、委員会に移動し、人をダブルクリックするか、プラス記号をクリックして、人を変更または追加できます。

インキュベーターのポッドリングコミッターにカルマを付与する方法

ポッドリングの承認は、PMCと同様にLDAPグループを使用して管理されます。Whimsy Rosterツールを使用してください。

すでにApacheアカウントを持っている人にカルマを付与する方法

この場合は、最初にPMCに連絡してください。すべてのPMCチェアは、既存のApache IDにプロジェクトのリポジトリへのアクセス権を付与できます。上記のハウツーを参照してください。ポッドリングの場合、PMCはインキュベーターです。

チェアはWhimsyのrosterツールを使用して、プロジェクトのメンバーシップリストを変更できます。

PMCチェアが応答しない場合、または利用できない場合のみApache Infraチームに連絡してください。これは、すでにApacheアカウントを持っていて、拡張コミットアクセスが必要な人のみに適用されます。

    
Karma request form:

    To: infrastructure
    Cc: private@<project>.apache.org, committers@email.address
    Subject: Karma request

    Userid:       ...

    Requested karma:  <project>[/<subproject>]...
    Reason:       [a few lines explaining why someone needs karma]

    [Vote:        reference to mail archive for PMC bookkeeping]

リクエストが受信されると、適切なアクセス権を持つ担当者がカルマを拡張し、それに応じて返信します。

他のApacheインフラストラクチャサーバーにアクセスする方法

ほとんどのコミッターは、Apache IDとプロジェクトのリポジトリおよびメーリングリストだけで必要なすべてのリソースにアクセスできます。ただし、他の公式ASFサーバーへのアクセスが必要な場合は、Apache Infraチームに連絡してアカウントをリクエストしてください。


    Account request form:

    To: infrastructure
    Cc: private@<project>.apache.org, committers@email.address
    Subject: Machine account request - <machine>

    Userid:     ...
    Machine:    ...
    Groups required:...
    Reason:      [a few lines explaining why an account is required]

    [Vote:       reference to mail archive for PMC bookkeeping]

その後、マシンの管理者がそれに応じて返信します。

PMCのFAQとハウツー

外部ソースからコードをインポートする方法

インポートするコードがカテゴリAライセンスでライセンスされており、元のライセンスでコードを配布する意図がある場合は、元のヘッダーを保持してコードをApacheソースリポジトリにコピーします。コードのライセンスをトップレベルのLICENSEファイルに追加します。チームがコードを変更する場合は、変更を記述したApacheヘッダーをファイルに追加します。

インポートするコードがApacheで継続的な開発を意図しており、コードの所有者が個人の貢献者ライセンス契約法人の貢献者ライセンス契約、またはソフトウェア付与契約に基づいてApacheに知的財産を貢献することを希望している場合は、ライセンスヘッダーを標準のApacheヘッダーに変更して、コードをApacheリポジトリにコピーできます。この場合、コードはインキュベーターによって知的財産クリアランスプロセスを通じてレビューされる必要があります。

プライベートリストのアーカイブを検索する方法

アーカイブが一般に公開されていないApacheリストが多数あります。これらのリストへの投稿は機密と見なされます。作成者の許可なしに、公共のリストやASF外で引用しないでください。

PMCメンバーは、プロジェクトのprivate@リストのアーカイブを検索できます。ASFメンバーと役員は、PMCメーリングリストのアーカイブを読むこともできます。プライベートアーカイブにアクセスするにはいくつかの方法があります。

プロジェクトのプライベートリストに誰がサブスクライブできますか?

プロジェクトのすべてのPMCメンバーは、そのプロジェクトのprivate@リストにサブスクライブする必要があります。さらに、ASFメンバーは、任意のプロジェクトのプライベートリストを読むことができます。一般に、PMCに属していない人は、ASFメンバーでない限り、private@リストへのサブスクライブを許可されるべきではありません。

メーリングリストへの自己サブスクライブが可能です。

PMCおよびLDAPメンバーシップを確認する方法

PMCおよびLDAPグループのメンバーシップを確認するには、主に2つの方法があります。

LDAPとcommittee-info.txtへの変更が電話帳アプリに反映されるまで、時間をください。

注:PMCメンバーシップの公式記録は、LDAP委員会グループではなく、committee-info.txtファイルです。

wiki、ブログ、または新しいメーリングリストをリクエストする方法

これらのリソースやプロジェクトに関するその他のリソースをリクエストするには、Contact Infraロードマップを参照してください。

プロジェクトのビジネスについてどこで議論すべきですか?

ほとんどすべての場合、プロジェクトのビジネスに関する議論は、そのプロジェクトの公開アーカイブされたメーリングリストで行われるべきです。詳細なポリシーでは、いくつかの例外について説明しています。

特に非公開にする必要がないトピックについては、適切な公開メーリングリストで議論してください。これにより、一般の人々がプロジェクトの方向性について読み、早期のフィードバックを提供できます。

ほとんどのプロジェクトは、dev@project.apache.org メーリングリストで作業を行います。一部のプロジェクトには、より一般的または技術的でない質問のためにuser@メーリングリストもあり、general@メーリングリストがある場合もあります。すべてのプロジェクトは、リストへのサブスクライブ方法とアーカイブを読むための手順が記載された明確なメーリングリストページを持っている必要があります。

ヘルプを得る方法または問題をエスカレートする方法

通常、Apacheプロジェクトは自分たちの問題を自分たちで管理することが期待されています。PMCのメンバーと定期的なコミッターは、通常、プロジェクトコミュニティ内で作業するための最善の方法を知っています。ただし、うまくいかない場合、またはプロジェクトコミュニティに深刻なポリシーに関する疑問がある場合や、協力方法に関する意見の相違がある場合は、ASFの他の場所でヘルプを求めることができます。

詳細なエスカレーションガイドは、Apacheの他のグループからヘルプを得る場所、または、どうしても解決できない場合に、理事会にヘルプを求めたり、問題を申し立てたりする方法をコミュニティが見つけるのに役立ちます。
Apache組織図は、法務、ブランディング、報道、またはASFがプロジェクトに提供するその他の多くのサービスなど、ほとんどの問題についてヘルプを求める適切な担当者またはグループを見つけるのに役立ちます。