Apacheのプロジェクト管理委員会（PMC）は、理事会に四半期ごとにプロジェクトの健全性と状況を報告する必要があります。PMCは独自に技術的な問題を管理していますが、プロジェクトが私たちの使命をサポートする、健全で、コミュニティ主導で、合意に基づくプロジェクトとして運営し続けることを確認するための監督を理事会が行います。 PMCの義務に関するFAQも参照してください。PMC議長とアパッチメンバーは常に毎月の理事会に出席できます。
内容
PMCの各議長は、報告スケジュールに従って、理事会ごとに少なくとも1週間前にプロジェクトの報告書を四半期ごとに提出する責任があります。
https://svn.apache.org/repos/private/committers/board/committee-info.txt
以下に記載されているように、遅れて報告したり、そのスケジュールどおりでなかったりしても、このスケジュールは変更されません。たとえば、1月に報告することになっていたが、それを逃して2月に報告した場合、次の報告は依然として4月に提出する必要があります。委員会が適切に審査するのに十分な時間内に報告書を提出しない場合、翌月に再提出するように依頼されます。
ほとんどの場合、議長は他のPMCメンバーと協力して報告書を作成しますが、報告書の完成と提出は最終的には議長の責任です。委員会は議長とPMCのprivate@メーリングリストの両方に、この作業を思い出させる自動リマインダーをいくつか送信します。
例外：新しく卒業したPMCは、アパッチのインキュベーターを離れてから最初の3か月間、月に1回報告書を提出する必要があります。アパッチのインキュベーターにまだ残っているすべてのポッドリングは、インキュベーターポッドリングのステータスプロセスを使用して同様の報告書を作成します。
委員会の月例会合の議題に報告内容を約束する必要があります。
Whimsy Agenda ツールまたは ComDev プロジェクトレポーターツールを使用します。これらは便利なフレームワークを生成します
https://whimsy.apache.org/board/agenda/
https://reporter.apache.org/
レポートの投稿ボタンをクリックしますコマンドラインのユーザーは、既存の形式に従ってレポートをチェックインできます。そうすることで、自動ツールがそれらを解析できます
https://svn.apache.org/repos/private/foundation/board/
ボードは、定期レポート以外に PMC が送信するレポートを歓迎します。レポートする重要な内容がある場合、またはフィードバックをリクエストする場合です。この場合、議長はレポートをアジェンダの最後に添付し、それに対応するコメントセクションを作成する場合があります
レポートの主な対象は取締役会ですが、レポートは会議後公開され、プロジェクトの年代順の履歴になることを覚えておいてください。コミュニティに知ってもらいたい情報を使ってレポートを作成し、将来レポートを閲覧する人にとって役立つ履歴になるようにすることをお勧めします
レポートの公開部分を、ユーザーリストまたはプロジェクトの Web サイトを通じてプロジェクトのコミュニティと共有することもできます
Apache 委員会レポーターツールを使用すると、レポートに使用するデータを簡単に集めることができます。ただし生成されたテンプレートを編集して、以下のポイントをカバーするために情報を追加する必要があります
レポートを送信するときは、TODO マーカーを残さないでください
これらのポイントはテンプレートとは異なります。プロジェクトでは、これらの箇条書きをレポートに単純にコピー アンド ペーストしないでください。むしろ、これらはあなたのプロジェクトの健全さと状態を評価するためにボードが知りたいトピックです。すべてのトピックがすべてのレポートに関連するわけではありません。ただし、議長はレポートを作成するときにこれらの質問をそれぞれ検討する必要があります。
プライマリソフトウェア製品の実際の機能を簡単に説明します。[必須]
例
The Apache Xerces XML parsing library is easily configurable
and compliant with current standards.
この説明は、メイン Web サイトで使用されているソフトウェア製品の基本的な商標説明に似ている必要があることに注意してください
ブランドの命名と説明を参照してください
以下のキーワードのいずれかを使用してプロジェクトの状態を示します。[必須]
もちろんこれは主観的ですが、プロジェクトのライフサイクル内での状況に基づいてボードの期待値を調整するのに役立ちます。必要に応じて、追加のコメントを歓迎します
プロジェクトの状態と健全性、およびコミュニティを数文で要約します
プロジェクトが過去四半期に行った主な作業を説明する段落でレポートを開始すると、読者は伝えたい重要なポイントを理解するのに役立ち、レポートをまとめたい人や財団全体で何が起こっているかについての情報を素早く収集したい人にも役立ちます。その後、ガイダンスを使用してこれらのポイントをレポートの残りの部分で詳しく説明できます
ボードは、プロジェクトが取り組んでいる技術的な変更とコミュニティの健全性の両方を検討しています。ユーザーの質問には回答されていますか? 貢献者は適切に行動していますか? 新しい貢献者が現れていますか?
ボードが対処するべき問題がありますか?
董事会应该注意，或者特别说明某些具体问题，那么请联系他们提出。如果没有，建议说明类似：“当前没有董事会级别的问题”。
有疑问时，最好在报告中包含 PMC 的信息或问题，而不是等待。另外请记住，可以通过私密存档的 board@apache.org 列表随时向董事会提出问题。
项目上一次发布是什么时候？[必填]
定期发布软件产品是项目健康的标志。报告应该列出过去一个季度发布的版本，包括发布日期。
注意：如果未发布任何版本，请列出最近一次发布的日期，以便董事会能确定项目发布已经过去了多长时间。
描述项目在过去一个季度中的总体活动情况。
通过简要讨论用户和开发人员列表的活跃程度，帮助董事会评估项目的活动情况和健康状况。用户的问题是否得到解答？正在进行新开发，还是只进行错误修复？开发社区是否定期阅读和回复用户电子邮件和问题？
注意：如果活动很少，请确认是否有至少三名活跃的 PMC 成员可以在需要时介入，并在此报告中包含此信息。
描述项目的当前计划
一个健康的项目通常会朝着一个共同的目标努力，或者对接下来该做什么有一个共同的理解——即使各个贡献者有他们自己的“偏好”。正在处理的主要功能是什么？计划发布什么？是否有正在进行的任何特定工作或开发分支？提供摘要，不要深入研究技术细节。
除了报告之外，如果项目计划重大公告，请通过 press@apache.org 联系市场营销和宣传委员会，以协调公告和新闻稿。
相反，如果活动很少，请讨论项目如何应对这种情况——是通过寻求新贡献者，保持休眠但可用的状态，还是准备移至 Apache Attic。如果您需要吸引新贡献者方面的帮助，可以向 Apache Community Development 寻求建议。
最新提交者或 PMC 成员何时当选？[必填]
一个健康的项目往往会定期添加新的提交者和 PMC 成员。
报告应表明最近添加提交者的日期和最近添加 PMC 成员的日期到您的项目，无论这些日期是否在当前报告期内。
PMC 和提交人员的多样性
一个健康的项目应该能经受住任何单一贡献者或贡献者雇主的离开。健康的项目也需要为多方服务。因此，ASF 希望项目具有多元化的 PMC 和提交人员。如果 PMC 对其多元化有任何担忧或认为这是一个问题，报告应包括有关其 PMC 中和提交人员中当前所代表的唯一组织数量的信息。
项目的品牌或命名问题，无论是在项目内部还是外部。
プロジェクトのブランド、つまり名前とロゴはApacheプロジェクトを識別する重要な方法であり、新しいユーザーがコントリビューターになるための主要な方法です。プロジェクトはそのブランドを一貫して使用していますか？プロジェクトの名前、ロゴ、または良好な評判を不適切に、またはプロジェクトに害を及ぼす方法で使用している第三者はいますか？
プロジェクトのWebサイトのブランディングが完了していない場合（チェックリストを参照）、ブランド委員会と協力して残りの項目を最終決定する方法に関する具体的な計画を含めます。
注:他のすべてのブランディングの問題は、理事会レポートに含めるのではなく、ブランディング委員会に持ち込みます。
法的問題や質問
法律委員会が法的問題を処理していますが、理事会レポートに発生した法的問題を必ず記載してください。
インフラストラクチャの問題または戦略的ニーズ
インフラストラクチャチームがプロジェクトに必要なサービスの提供の詳細を処理していますが、理事会レポートに懸念事項や戦略的な提案、リクエストを遠慮なく含めてください。
レポートにプロジェクト関連の商業活動を支配させないでください。
各ApacheプロジェクトのPMCはプロジェクトを管理します、第三者や外部組織ではありません。プロジェクトレポートはプロジェクトに関するものでなければならず、プロジェクトの健全性に直接関係しない限り、外部組織の活動について議論するべきではありません。
レポートに私的な事項を含めないでください。明確にマークを付ける（下記参照）。
非Apache URL短縮サービスを使用しないでください。
レポートに含めたい長いURLがある場合は、Apacheログインが必要なhttps://s.apache.org/URL短縮サービスのみを使用して、より短いリンクを作成してください。Apacheは、外部URL短縮サービスがどれくらい存在し続けるか、または特定の短縮URLを維持するかを制御できません。メーリングリストスレッドに言及する場合、同じ理由でhttps://lists.apache.orgURLのみを使用してそのメーリングリストスレッドにリンクしてください。
コミッターのアフィリエイトに関する詳細をレポートに含める必要はありません。ただし、多様性に関する問題を示す情報をプライベートに含めることはできます。
まれに、プロジェクトはプライベートに理事会に何かを報告する必要がある場合がありますが、公開議事録に情報を掲載したくありません。Apache理事会レポートはすべて公開され、通常は理事会開催から1、2か月後であることを覚えておいてください。
そのような情報はレポートに含めても構いませんが、次のように含めてください。
<private>
と
</private>
マーカーは、それぞれが別々の行にあるようにしてください。そうすることで、公開議事録から何を省略するかを知ることができます。プライベートマーカーが機能していることを確認するには、レポを Whimsy に投稿して、ページを更新します。
適切にマークされたプライベートセクションは、グレーの背景で表示されます。
問題が非常に機密でプライバシーを非常に気にしている場合は、代わりにboard-private@または個々の理事会メンバーに直接メールを送信できます。理事会メンバーが情報を理事会に中継します。
プロジェクトレポートは、理事会にプロジェクトのステータスと健全性を知ってもらうための重要な方法です。Apacheのプロジェクトの多様性により、これらのガイドラインではすべての状況に対応できません。プロジェクトについて重要なと思われる追加情報をレポートに遠慮なく含めてください。
特に、PMCの委員長や他のメンバーがプロジェクトに潜在的なものを含む「問題のある箇所」を見つけた場合、取締役会レポートに必ずメモをつけてください。取締役会が後に問題を発見する可能性があることよりも、レポートに懸念事項（またはPMCの一部の懸念事項）を含めた方がよいでしょう。
最後に、レポートを作成するのに十分なアクティビティがないように思えるプロジェクトが見つかった場合は、その事実を必ず報告してください。健全なプロジェクトは、アパッチアティックに向かっている場合に認識する必要があります。アティックに移動することは失敗ではありません。プロジェクトが成熟したり、漂ったり、他のテクノロジーに取って代わられたりした可能性があることを認識しているだけです。私たちはそれを認識する必要があります。
取締役会はプロジェクト委員長のレポートに依拠して、プロジェクトのステータスと健全性を理解しています。取締役会がプロジェクトの進行状況について十分に認識できない場合、近い将来フォローアップレポートをお送りします。
プロジェクトレポートは一方向のコミュニケーション形式ではありません。取締役会に参加する機会でもあります。プロジェクト委員長はゲストとして取締役会に出席してレポートについて話し合うことができます。また、取締役会に検討してほしい特定の問題を強調することもできます（レポート内またはアジェンダの広範な議題の項目を要求します）。
もちろん、委員長は報告期間の内外を問わず、いつでもBoard@メーリングリストでこれらの議論の機会を利用することもできます。
レポートを提出する必要があるたびに、ディレクターがプロジェクトレポートの「シェパード」としてランダムに割り当てられます。彼らは、レポートが遅れた場合のフォローアップ、重要なコメントや承認がない場合は会議中のレポートの説明、および会議後のPMCへのフォローアップメッセージまたはアクションの伝達を担当します。
ディレクターが会議に向けてレポートを見直すとき、彼らはレポートの横にアジェンダにコメントを追加することがあります。SVNのコミットを監視したり、Whimsy Agendaツールを使用したりして、プロジェクト委員長がその取締役会からのフィードバック（現在）をフォローし、実行可能な場合は会議の前に対応することをお勧めします。
取締役会は通常、このパターンに従います。
ご覧のとおり、レポートを期日までに受け取り、必要な詳細がすべて含まれ、コメントに対処することで、理事会会議の進行状況が大幅に向上します。理事会会議では毎月 80 以上のプロジェクト レポートとポッドリング レポートに加えて、他の業務分野を含める必要があります。