この用語集は、ASFおよびApacheプロジェクトで使用される組織用語の簡単な説明を提供します。Apacheに関する詳細については、/dev ドキュメントまたはコミュニティ開発プロジェクトを参照してください。
プロセス、通常はリリース準備プロセスの結果として作成されるファイル。
Apache Software Foundation、非営利組織。
廃止された、放棄された、および引退したコードベースおよびプロジェクトの場所。Apache Atticプロジェクトは、アクティブな作業とは明確に区別しながら、将来の参考や再活性化の可能性のために情報を保存します。
メンバーによって選出されたASFの9人からなる法的な統治機関。理事会は、財団の活動と運営を監督し、ASFの定款を適用および施行します。とりわけ、理事会は、ASF プロジェクトの作成または解散、資金要請、法的問題、および懲戒処分など、提示された決議を承認または拒否します。オープンな非営利法人として、ASFは理事会の議事録をhttps://apache.dokyumento.jp/foundation/records/minutes/で公開しています。これらの議事録には、幹部会で決定されていないすべての決定が含まれています。理事も参照してください。
バイク小屋をどの色で塗るかについて（無意味に）議論すること。ここで説明されているように、議論が非常に些細なため、誰もが簡単に意見を持ち、自分の意見を優先させたい場合に発生する可能性があります。
ビルドは、一般への配布には適さないパッケージです。ビルドは進行中の作業であり、財団で製品開発に携わっている人のみが利用できるようにする必要があります。
定款は、組織が従う規則を成文化したものです。ASFの定款など、一部は法的に拘束力があり、組織外でも重要です。Jakartaの定款など、他の定款はコミュニティ内でのみ意味があり、コミュニティ自体がそれらを拘束力のあるものにする場合にのみ拘束力があります。ASF内の組織の定款は、ASF自体の定款と矛盾してはなりません。組織の定款におけるそのような矛盾する部分は、必然的に無効です。
1. ASFの理事の理事会の議長。理事会の円滑な会議と機能に責任を負います。2.プロジェクト管理委員会PMCなどの委員会の公式責任者。PMC議長は、ASFの副社長であり、プロジェクトの適切な運営を担当します。
意味のあるソースのグループ。一部のプロジェクトは単一のコードベースのみを使用しますが、複数のコードベースを持つプロジェクトもあります。
ASF プロジェクトは、バージョン管理ソフトウェアを使用して、コードの変更を調整します。そのコードに直接変更を加える能力は、コミットアクセス（[VCS] commitサブコマンドから）として知られています。このプロセスは、実際の公式コードにパッチを適用します。また、Karmaも参照してください。
（しばしば「CTR」または「C-T-R」と省略されます。）開発者が自由にコードを変更できる一方、変更が事後的に拒否される可能性のあるコード変更を管理するポリシー。C-T-Rは、レイジーコンセンサスによる意思決定の適用です。C-T-Rモデルは、迅速なプロトタイピング環境で役立ちますが、必須のレビューがないため、R-T-Cの代替手段よりも日常的な業務で多くのバグを通してしまう可能性があります。R-T-Cを比較し、投票プロセスの説明を参照してください。
共通の目的を持つ個人のグループ。プロジェクトのコミュニティは、そのプロジェクトに関心のあるすべての人で構成されています。
ASFの公式な開発者およびユーザーカンファレンス（コミュニティ・オーバー・コードのWebサイトを参照）。
「コンセンサス承認」とは、少なくとも3つの拘束力のある+1票と拒否権なしで完了した投票（意味1）を指します。多数決承認を比較してください。
ASF PMCの下のエンティティ、コード、ドキュメントなどに一貫した改善を加える人。これ自体は、コミットアクセスを意味するものではありませんが、頻繁かつ価値のある貢献者は、そのようなアクセスに対してすぐに投票されます。
コントリビューターライセンス契約（CLA）は、個人コントリビューターライセンス契約（ICLA）と呼ばれることもあります。企業コントリビューターライセンス契約（CCLA）もあります。すべて、ライセンスページで説明されています。
Concurrent Versioning System、古いバージョン管理システム。
ソフトウェアダーウィニズムを参照してください。
コードまたはドキュメントの形でプロジェクトに貢献するユーザーは、開発者になります。彼らはプロジェクトに参加するために追加の手順を踏み、開発者のメーリングリストで積極的に活動し、議論に参加し、パッチ、ドキュメント、提案、批判を提供します。開発者は「コントリビューター」とも呼ばれます。
メンバーによって財団の理事会に毎年選出される9人の個人のうちの1人。理事は個別の責任を負う場合とそうでない場合がありますが、理事会は財団全体を監督するため、一般的に全員が財団の運営と活動についてできるだけ多くの情報を把握しておくことが期待されます。
もはや活動的ではないが、依然としてその役職の多くの権利と特権を有する者を正式に指定するために使用される用語。たとえば、長期間メンバーシップ会議に出席していないASFメンバーは名誉職として宣言されます。特定のプロジェクトに取り組む時間がない人は、自分自身を名誉職と宣言する場合があります。名誉職のステータスは、辞任した場合とは対照的に、活動ではなく関心を示します。
小さな変化を徐々に蓄積することによる進歩。Apacheプロジェクトの典型的なモード。革命を比較してください。
理事会会議の一部であり、機密事項に関係しており、したがって公に議事録を作成することはできません。例としては、給与に関する議論、秘密保持契約の対象となる分野、懲戒処分、および一部の種類の資金調達の決定などがあります。
大多数のASFプロジェクトで使用されるバージョン管理システム。
ASFの参加者が集まり、交流し、興味に応じて議論/議論/ハック/プロトタイプを作成できる非公式イベント。ハッカソンはすべてのコミッターと招待されたコントリビューターに公開されており、通常はApacheConイベントの直前または直後に開催されます。
代謝率が低下した睡眠のような状態。活動レベルの低いプロジェクトを説明するために使用されることがあります。
インキュベーターは、ASFへの参加を希望するプロジェクトにサービスを提供します。
これにより、これらの参加プロジェクト（「ポッドリング」と呼ばれます）は、Apacheスタイルのガバナンスと運営を採用し、トップレベルのASFプロジェクト（「TLP」）になることができるように、プロジェクトで利用可能なASFサービスに導かれます。
インキュベータープロジェクト管理委員会。
ApacheインキュベーターはトップレベルのASFプロジェクトでもあるため、独自のPMCも持っています。
1. バージョン管理への変更のコミットなど、操作を実行するための十分なアクセス権。（「foo-bar に Yo Mega のカルマを付与してください。」）2. コミュニティにおける尊敬とメリット。（「Al Faa と Ro Main は、慎重かつ如才ない議論と技術的な貢献の質によって、良いカルマを得ている。」）3. 1と2の意味の組み合わせ。間接的な関係がある。
（「レイジーアプルーバル」とも呼ばれる。）定義された期間内に反応が投稿されない場合、一般的な同意があったと見なす意思決定ポリシー。例えば、「今後3日以内に反対がなければ、レイジーコンセンサスでこれをコミットします。」コンセンサスアプルーバル、マジョリティアプルーバル、および投票プロセスの説明も参照してください。
（完全なライセンステキストを含めるのではなく）コードファイルの先頭にある、そのファイルのライセンスを参照するテキスト。
少なくとも3つの拘束力のある+1票があり、-1票よりも+1票が多い投票（1の意味）を指します。（つまり、最低定足数3票の単純過半数）。マジョリティアプルーバルを必要とする投票では、-1票は単なる反対票であり、拒否権ではありません。コンセンサスアプルーバルと比較してください。投票プロセスの説明も参照してください。
「インキュベーションメンター」とも呼ばれる。
インキュベーターは、各ポッドリングに対して、さまざまなASFチーム（インキュベーターPMC、インフラストラクチャチームなど）との連絡役を務め、ポッドリングの成長と運営を促進するメンターを任命します。
ASFではこの用語を3つの意味で使用するため、文脈から明らかな場合を除き、どの意味で使用しているかを明記することが重要です。
「メリット」という概念は、Apacheの哲学およびコミュニティの方法論の中心です。メリットとは、個人の業績の価値と、同僚からの尊敬の組み合わせを指す、質的かつ主観的な用語です。
メリットの獲得は累積的なプロセスです。一度獲得すると、減衰することはありません。ただし、コミュニティの倫理、ガイドライン、または感受性を侵害することによって、メリットを失う可能性があります。
メリットクラシーは、ASFとその哲学の根底にある原則の1つです。「より多く行えば行うほど、より多くのことができるようになる」と言われています。人がメリットを獲得するにつれて、コミュニティにおけるその人の地位と、その意見に与えられる重み（ある程度）が増大します。
ネットエチケットは、オンラインでの良好な行動に関する一般的な規則です。一般的なケースについては、IETF RFC 1855で定義されています。より具体的なApache環境については、次のようなものに集約されます。
これらは、リストごとにルールがより（またはより少なく）なる可能性のある事柄の概要にすぎません。「礼儀正しくする」および「他の人に不必要な作業をさせない」に集約されます。
ソフトウェアリリースパッケージのNOTICEファイルは、LICENSEのテキストまたはバンドルされた依存関係に埋め込まれたライセンス情報では満たされない、法的に義務付けられた通知の特定の部分に予約されています。NOTICEの変更を参照してください。また、Apache Licenseのセクション4dも参照してください。
ASF理事会によって任命され、財団の活動の一部に対して特定の権限と責任を与えられた個人。役員は、財団の理事である場合とそうでない場合があります。
パッケージとは、配布を目的としてプロジェクトのソースコードから作成された圧縮アーカイブファイルです。パッケージは通常、ソースパッケージまたはソースから構築されたバイナリパッケージのいずれかです。場合によっては、ソースパッケージとともに個別のドキュメントパッケージがリリースされます。多くの場合、パッケージには、前提条件として追加のソフトウェアをインストールする必要がある外部依存関係があります。
プロジェクト管理委員会。 プロジェクトの正式な監督を行う人々のグループ。 PMCの議長は常に財団の役員です。 PMCは理事会によって割り当てられた公式の監督責任を負っているため、その活動は、暗示されるすべての法的保護と責任とともに、財団を代表して行われたと見なされます。定款を参照してください。
PMCのメンバーを「PMC」と呼ぶことは避けてください。グループについて話しているのか、個人について話しているのかについて混乱を招く可能性があります。
インキュベーションプロセス中のコードベースと、そのコミュニティ。インキュベーションプロセスの説明を参照してください。
ポッドリングプロジェクト管理委員会。 ポッドリングの正式な監督を行う人々のグループ。
Apache Software Foundationでは、「プロジェクト」という用語は通常、1つ以上のコードベースに焦点を当て、PMCによって監督されるコミュニティを指します。
リリース準備ができているかどうかを確認するために検査されるソースパッケージおよびその他の付随するアーティファクト。その後、PMCは候補をリリースするかどうかを投票します。
リリースプロセスを通じて最終的な配布までリリースを管理する責任を負う個人。プロジェクトのコミッターは、リリース管理者として機能できます。「RM」と略されることがよくあります。
（「RTC」または「R-T-C」とよく参照されます。）すべての変更がコードベースにコミットされる前にコンセンサスアプルーバルを受けることを要求するコミットポリシー。C-T-Rと比較し、投票プロセスの説明を参照してください。
Apache環境では、一部のコミュニティでは、特に拒否権によって特定のブランチでブロックされているコード変更の場合に、意見の相違を調整する方法として革命を許可（または推奨）する場合があります。もともとJames Duncan Davisonが彼の「革命家のためのルール」で説明した概念は、少なくとも1つのApache プロジェクトで、正式または非公式に採用されています。基本的に、革命は、コミッターのグループが、問題のあるコードまたは概念に取り組むために、現在のメインブランチをフォークすることを決定した場合に発生します。これにより、メインブランチでの進化的な作業を妨げることなく、それを追求できます。革命的なブランチは、最終的にメインブランチにマージされるか、消滅するか、完全に分割して新しいメインブランチになるか、現在のメインブランチを吸収する可能性があります（基本的に最初のオプションと違いはありません）。「革命家のためのルール」を参照し、進化と比較してください。
リリースとは、The Apache Software Foundationが一般に提供するパッケージです。
レビューしてからコミットを参照してください。
「最高のコードが生き残る」とよく表現される、一見単純な概念。Apacheピアレビュー環境に固有の進化プロセスは、この考え方を支持します。
SGAの詳細を参照してください。
ほとんどのApache開発プロジェクトで実践されている非対話型のコミュニケーションスタイルにより、行われた決定と進行中の決定の記録を維持することは有益なことです。多くのApacheプロジェクトは、プロジェクトのコードリポジトリに格納された、通常STATUSという名前のファイルを使用してこれを実現しています。既存の開発者に現在の問題を知らせるだけでなく、そのようなファイルは、プロジェクトを調査する可能性のある新しい開発者にも役立つ情報を提供します。
単記移譲式投票。たとえば、Apache理事選挙で使用されます。http://en.wikipedia.org/wiki/Single_Transferable_Voteを参照してください。
「CVSに代わる魅力的なもの」であるバージョン管理システム。少数のプロジェクトがSubversion（SVN）を使用しています。
Subversionを参照してください。
「tabled」という用語は、理事会の議事録で見られることがあります。例えば、「特別決議7Hは、...、tabledされた。」という場合、その文脈では「延期された」または「先送りされた」という意味になります。
トップレベルプロジェクト。 PMCも参照。
ASF（Apache Software Foundation）の会計担当（Treasurer）は、法人の役員であり、財団の資金と資産の管理、税務情報の報告などを担当します。会計担当は、財団のメンバーである必要も、理事である必要もありませんが、多くの場合、メンバーや理事のいずれかがその役割を務めます。
いくつかの定義
トロールへの対処方法については、このスレッドを参照してください。（せっかちな人のために）Tedの意見（良いまとめ）も参照してください。
私たちのソフトウェアを使用する人。ユーザーは、バグレポートや機能提案の形で開発者にフィードバックを提供することで、Apacheプロジェクトに貢献します。ユーザーは、メーリングリストやユーザーサポートフォーラムで他のユーザーを支援することで、Apacheコミュニティに参加します。
バージョン管理システムは、ファイルへの増分的な変更を追跡（および場合によっては元に戻す）する機能を提供し、変更が加えられるとメーリングリストに報告します。また、多くの開発者が同時に使用できます。財団のすべてのコードとドキュメントは、このようなシステムで管理されており、各コードベースの完全な履歴が提供されます。Git、Subversion、CVSを参照してください。
Apacheの方法論によれば、行われたまたは提案された変更は、該当するコードベースへのコミッターによる拒否権の行使によって阻止される可能性があります。R-T-C（レビュー後コミット）のコミットポリシーが有効な場合、拒否権はその変更の実行を妨げます。R-T-CまたはC-T-R（コミット後レビュー）環境のいずれにおいても、すでに行われた変更に対して拒否権が行使された場合、その変更は元に戻されます。拒否権は覆すことも投票で否決することもできず、拒否権を発行したコミッターがそれを取り下げた場合にのみ適用されなくなります。すべての拒否権には、正当な技術的根拠が必ず伴っていなければなりません。そのような根拠のない拒否権は無効です。疑わしい場合は、技術的根拠が有効かどうかを判断するのはPMCの役割です。拒否権は議論を促し、支持されれば、バージョン管理によるロールバックまたは適切なコード変更につながります。拒否されたコードコミットは、緊急の解決策が必要な場合（例：ビルドの破損）を除き、元のコミッターによって元に戻すのが最適です。拒否権はコードまたはドキュメントの変更にのみ適用され、ソフトウェアリリースなどの手続き上の問題には適用されません。
ASFの副社長は、法人の役員であり、財団の特定の分野の業務に対する権限と責任を負います。PMCの議長は、それぞれのプロジェクトの適切な運営を担当する副社長です。
1. 正式な決定を行うプロセス。（「fooに対する投票は3日後に締め切られます。」）
2. 正式な決定の一部として、賛成または反対の意見、または拒否権を表明すること。（「fooは不快な臭いがするので、私の投票は-1です。」）
拘束力のある投票とは、決定が適用されるプロジェクトのPMCコミッターによって行われた投票です。他の人が行った投票は、助言または示唆のみです。
ConsensusApproval（コンセンサス承認）、MajorityApproval（多数決承認）、LazyConsensus（怠惰なコンセンサス）、および投票プロセスの説明も参照してください。