プロジェクト細則
Apache Ant™ プロジェクト細則
この文書では、Apache Ant プロジェクトを運用する細則を定義します。プロジェクトの役割と責任、投票権のある人物、投票の仕組み、紛争の解決方法などを定義します。
Ant は Apache Software Foundation のプロジェクトです。同団は Ant コードベースのコードを含む Apache コードの著作権を保持しています。同団の FAQ には、同団の運用と背景が説明されています。
Ant は一般的に Apache プロジェクトの例であり、総称して「Apache 流儀」と呼ばれる一連の原則に基づいて運用されています。Apache の開発に初めて携わる場合は、Incubator プロジェクト を参照して、Apache プロジェクトの運用方法について詳しく情報を得てください。注: Incubator プロジェクトは最近立ち上げられたばかりで、まだ Apache 流儀について非常に詳しく説明していません。
役割と責任
Apache プロジェクトは、関連する権利と責任を含む一連の役割を定義しています。これらの役割は、プロジェクト内で個人が行うことができるタスクを管理します。役割は、次のセクションで定義されています。
ユーザー
プロジェクトの最も重要な参加者は、ソフトウェアを使用する人々です。開発者の大多数はユーザーとしてスタートし、ユーザーの視点から開発の取り組みを指揮します。
ユーザーは、バグレポートや機能の提案という形で開発者にフィードバックを提供することで、Apache プロジェクトに貢献しています。また、ユーザーはメーリングリストやユーザーサポートフォーラムで他のユーザーを支援することで、Apache コミュニティに参加しています。
開発者
Ant プロジェクトに時間、コード、ドキュメント、またはリソースを貢献しているボランティア全員。プロジェクトに継続的に歓迎される貢献を行っている開発者は、コミッターになるように招待される場合があります。このような招待の正確なタイミングは、多くの要因によって異なります。
コミッター
プロジェクトのコミッターは、プロジェクトの技術管理を担当しています。コミッター全員がプロジェクトのソースリポジトリへの書き込みアクセス権を持っています。コミッターは、プロジェクトに関する技術的な議論について拘束力のある投票を行うことができます。
コミッターへのアクセスは招待制でのみ与えられ、アクティブな PMC メンバーの消極的なコンセンサスによって承認される必要があります。コミッターは、独自の宣言により、または 6 か月以上プロジェクトに何らかの形で貢献しないことで、エメリタスと見なされます。エメリタスコミッターは PMC にコミットアクセスの再付与を要求できます。このような再付与は、アクティブな PMC メンバーの消極的なコンセンサスに従います。
コミットアクセスは、アクティブな PMC メンバー全員（問題のコミッターが PMC メンバーの場合、そのコミッターを除く）の満場一致の投票によって取り消すことができます。
Apache のすべてのコミッターは Apache ソフトウェア財団と締結した Contributor License Agreement (CLA) に署名して、それをファイルとして提出する必要があります。コミッターの要件について詳しい情報は、Commiter FAQ に記載されています。
プロジェクトに継続的に貢献しているコミッターは、PMC のメンバーになるよう求められることがあります。貢献の形はコードだけに限定されません。コードレビュー、メーリングリストでのユーザーのサポート、ドキュメントの執筆などにも及びます。
プロジェクトマネジメント委員会
Apache Ant のプロジェクトマネジメント委員会 (PMC) は、2002 年 11 月 18 日に Apache ソフトウェア財団の役員会の決議によって設立されました。PMC は、Apache Ant のコードベースの管理と監督について、管理委員会と ASF に対して責任を負います。PMC の責務には以下のものがあります。
- Apache Ant プロジェクトの製品として配布されるものの決定。特にすべてのリリースは PMC の承認を得る必要があります。
- コードベースレポジトリ、メーリングリスト、ウェブサイトを含むプロジェクトの共有リソースの管理。
- プロジェクトの代表者としての活動。
- プロジェクト製品に関するライセンス紛争の解決。
- 新しい PMC メンバーとコミッターの推薦。
- これらの細則とプロジェクトのその他のガイドラインの管理。
PMC のメンバーは招待のみで、その上でアクティブな PMC メンバーの消極的コンセンサスによって承認される必要があります。PMC メンバーは、自分自身が宣言した場合または 6 か月以上プロジェクトに何らかの形で貢献していない場合、「名誉会員」と見なされます。名誉会員は PMC のメンバーとして復帰するよう申請することができます。この復帰は、アクティブな PMC メンバーの消極的コンセンサスに従います。PMC のメンバーシップは、関係者以外のすべてのアクティブな PMC メンバーの一致した投票によって取り消すことができます。
PMC の委員長は ASF 管理委員会によって任命されます。委員長は Apache ソフトウェア財団の役員 (バイスプレジデント、Apache Ant) であり、Ant PMC の範囲内のプロジェクトの管理について管理委員会に対する主要な責任を負います。委員長は Ant プロジェクト内の展開について四半期ごとに管理委員会に報告します。PMC は毎年 PMC 委員長の職位を検討でき、3/2 の多数決で承認された場合、新しい委員長を管理委員会に推薦できます。最終的には、PMC 委員長として任命する責任は管理委員会が負います。
意思決定
Ant プロジェクト内では、さまざまな種類の決定に異なる形式の承認が必要です。たとえば、前の項では、「消極的コンセンサス」による承認を必要とする複数の決定について説明しました。この項では、投票の実行方法、承認の種類、およびそれぞれの承認の種類に必要な決定の種類について定義しています。
投票
プロジェクトに関する決定は、プライマリプロジェクト開発メーリングリスト (dev@ant.apache.org) での投票によって行われます。必要に応じて、PMC の投票は非公開の Ant PMC メーリングリストで行われる可能性があります。投票は、件名行が [VOTE] または [PMC-VOTE] で始まることによって明確に示されます。投票には複数の承認項目が含まれていることがあり、それらは明確に区別する必要があります。投票は投票メールへの返信によって行われます。投票には 4 種類あります。
| +1 | 「賛成」、「同意」、または「アクションを実行する必要があります。」一般的に、この投票は、有権者が「それを実現する」ことに意欲的であることも示します。 |
| +0 | この投票は、検討中のアクションを実行することに対する意欲を示します。ただし、投票者は支援できません。 |
| -0 | この投票は、投票者が一般的には提案されたアクションに同意しないことを示しますが、アクションの進行を阻止するほど懸念していません。 |
| -1 | これは反対投票です。コンセンサスが必要な問題では、この投票は拒否権としてカウントされます。すべての拒否権には、拒否権が適切である理由を説明する必要があります。説明がない拒否権は無効です。-1 投票に代替措置を含めることも適切な場合があります。 |
Ant プロジェクトのすべての参加者は、投票によって特定の行動に賛成か反対かを表明することが推奨されます。テクニカルな意思決定の場合、アクティブコミッターの投票のみが拘束力を持っています。拘束力を持たない投票も、拘束力のある投票権を持つ人がより広範な Ant コミュニティでの行動の認識を理解するのに役立ちます。PMC の意思決定の場合、PMC メンバーの投票のみが拘束力を持っています。
Ant コードベースに加えられる変更にも投票を適用できます。これらは一般的に、コミットが行われたときに送信されるコミットメッセージに対する拒否権 (-1) の形式を取ります。
承認
要求できる承認のタイプを次に示します。異なるアクションには異なる类型的承認が必要です
| コンセンサス | これを可決するには、拘束力のある投票権を持つすべての投票者が投票する必要があり、拘束力のある拒否権 (-1) があってはなりません。コンセンサス投票は、資格のあるすべての投票者の投票を得ることが現実的ではないため、ほとんど要求されません。 |
| レイジーコンセンサス | レイジーコンセンサスには、3 つの拘束力のある +1 投票と、拘束力のある拒否権は必要ありません。 |
| レイジー多数決 | レイジー多数決の投票では、3 つの拘束力のある +1 投票と、-1 投票よりも多くの拘束力のある +1 投票が必要です。 |
| レイジー承認 | レイジー承認のあるアクションは、-1 投票が届かない限り暗黙的に許可されますが、その時点で、アクションの種類に応じて、レイジー多数決またはレイジーコンセンサス承認を取得する必要があります。 |
| 2/3 多数決 | 一部のアクションでは、可決するためにアクティブコミッターまたは PMC メンバーの 2/3 の多数決が必要です。このようなアクションは通常、プロジェクトの基盤に影響します (たとえば、既存の製品に取って代わる新しいコードベースを採用する場合)。より高いしきい値は、そのような変更が強力にサポートされるように設計されています。この投票に可決するには、拘束力のある投票権保持者の少なくとも 2/3 が +1 に投票する必要があります |
拒否権
有効で拘束力のある拒否権は覆すことができません。拒否権が投じられた場合は、拒否権の理由を説明する有効な理由を添える必要があります。拒否権の有効性は、異議を申し立てた場合、拘束力のある投票権を持つ誰でも確認できます。これは必ずしも拒否権に同意することを意味するのではなく、拒否権が有効であることを意味するだけです。
有効な拒否権に同意できない場合は、拒否権を行使した人にロビー活動を行って拒否権を撤回してもらう必要があります。拒否権が撤回されなかった場合、拒否権を行使されたアクションは適時に取り消す必要があります。
アクション
このセクションでは、プロジェクト内で実施されるさまざまなアクション、そのアクションに必要な承認、およびそのアクションに対する拘束力のある投票権を持つ人を説明します。
| アクション | 説明 | 承認 | 拘束力のある投票 |
|---|---|---|---|
| コード変更 | コミッターによってプロジェクトのコードベースに加えられた変更で、コミットされた変更。これには、ソースコード、ドキュメント、Web サイトのコンテンツなどが含まれます。 | レイジー承認、その後レイジーコンセンサス。 | アクティブコミッター。 |
| リリースプラン | リリースのタイムテーブルとアクションを定義します。このプランではリリースマネージャーも指名されます。 | レイジー多数決 | アクティブコミッター |
| 製品リリース | プロジェクトの製品の 1 つがリリースできる状態になったら、リリースをプロジェクトの公式リリースとして受け入れるための投票が必要です。 | レイジー多数決 | アクティブな PMC メンバー |
| 新しいコードベースの採用 |
リリース済み既存製品のコードベースを別のコードベースに置き換える場合に使用します。このような投票が承認を得られなかった場合、既存のコードベースは継続されます。 これは、プロジェクト内の新しいサブプロジェクトの作成も対象とします |
2/3 多数決 | アクティブコミッター |
| 新しいコミッター | プロジェクトに新しいコミッターを提案する場合 | レージーコンセンサス | アクティブな PMC メンバー |
| PMC の新しいメンバー | PMC にコミッターを提案する場合 | レージーコンセンサス | アクティブな PMC メンバー |
| コミッターの削除 |
コミット権限の削除が求められる場合 注意: そのような行為は、PMC チェアによって ASF ボードにも紹介されます |
コンセンサス | アクティブな PMC メンバー（PMC のメンバーである場合は対象のコミッターを除く） |
| PMC メンバーの削除 |
PMC メンバーの削除が求められる場合 注意: そのような行為は、PMC チェアによって ASF ボードにも紹介されます |
コンセンサス | アクティブな PMC メンバー（対象のメンバーを除く） |
投票の時間枠
すべての有効投票者が投票を検討する時間を確保するため、投票は 1 週間開かれます。コード変更に関する投票は、厳密なスケジュールに従う必要はありませんが、可能な限り短時間に完了させる必要があります。