コミュニティプロセス

このページの目的は、Play Frameworkにおける意思決定プロセスを透明化することです。これはPlayプロジェクトを統括する法律ではなく、このドキュメントに記載されている内容は新しいものではありません。単に既存のプロセスを認め、それを文書化しているだけです。

このページの目標は、以下のことを行うことで、コミュニティへの貢献とPlayプロジェクトに対するオーナーシップ意識を高めることです。

• Playコミュニティに新しく参加した人にとって、意思決定がどのように行われ、誰が意思決定を行い、新しい人がどのように意思決定の責任を得ることができるかを明確かつ透明にすること。
• Playにおける意思決定プロセスの具体的な定義を提供することで、必要に応じて参照したり改善したりできるようにすること。

プロジェクトのオーナーシップ

PlayプロジェクトのソースコードはApache 2ライセンスの下でライセンスされています。運営委員会は、プロジェクトの製品に関する決定と技術的な決定の両方について最終決定権を持ちます。

運営委員会はすべての決定について最終決定権を持っていますが、Playのコアに400人以上のコミュニティコントリビューター、そしてより広範なPlayエコシステムにはさらに数百人のコントリビューターがいるPlayコミュニティは、Playプロジェクト自体と同様に重要であると言えます。場合によっては、それ以上に重要です。

このため、運営委員会とPlayプロジェクトの関係は、スチュワードシップとして最もよく表されます。運営委員会はPlayプロジェクトを管理しますが、Playコミュニティによって説明責任を負います。

運営委員会の詳細については、スポンサーページをご覧ください。

定義

コントリビューター

コントリビューターとは、Playに貢献するすべての人です。これは必ずしもコードの貢献を意味するわけではなく、以下のいずれかを意味する可能性があります。

• コードの修正、改善、新機能
• ドキュメントの修正、改善、新機能
• ドキュメントを他の言語に翻訳する
• Playのプラグイン、モジュール、ライブラリの作成または保守
• GitHubでのコードレビュー
• 問題の解決に役立つ情報の提起、トリアージ、追加
• Discussフォーラムでのデザインと機能に関する議論への参加
• DiscussフォーラムやStack Overflowでの質問への回答
• Play Frameworkに焦点を当てたユーザーグループの運営、講演、貢献
• カンファレンスでの講演、ブログへの投稿、その他のPlay Frameworkのプロモーション

インテグレーター

インテグレーターとは、Playプロジェクト、またはplayframework GitHub organization傘下のプロジェクトのソースコードとドキュメントへの書き込みアクセス権を持つすべての人です。すべてのインテグレーターの現在のリストは、コードとコントリビューターページにあります。

Playに貢献するためにインテグレーターである必要はなく、実際、インテグレーターでなけれればできない貢献と見なされるものはありません。実際には、インテグレーターだけが実行できることは、他のコントリビューターからの貢献のマージや、修正済みまたは無効な問題のクローズなどのイシュートラッカーのハウスキーピングタスクなどの管理タイプのタスクです。

意思決定

Playプロジェクトの意思決定は、大きく2つのカテゴリに分類されます。

• 実装の決定。これには、プルリクエストがマージされる基準を満たしているかどうか、機能や改善をどのように実装するかが含まれます。
• 設計とハウスキーピングの決定、つまりその他すべて。これには、主要な設計上の決定、ロードマップ、リリーススケジュール、プロジェクトの実行と管理方法に関する決定、使用するツールなどが含まれます。

実装の決定

実装の決定は、主にプルリクエストで行われます。プルリクエスト自体によって開始され、レビューと反復を通じて、特定の変更の実装方法についてコンセンサスが形成されます。

すべての利害関係者は、プルリクエストのレビューとレビューの議論への参加を奨励されています。

プルリクエストがマージされるかどうかに必要なコンセンサスの量は、プルリクエストの影響の大きさに依存します。ドキュメントの修正などの些細な変更については、インテグレーターは他のインテグレーターからのフィードバックなしにマージすることができます。大きな変更の場合は、変更されているコードの部分に精通している少なくとも1人がレビューする必要があります。できれば複数人がレビューする必要があります。大規模なリファクタリングの場合は、プルリクエストをマージする前に、少なくとも2人または3人の他のインテグレーターがレビューする必要があります。

プルリクエストがマージされるかどうかは、多くの要因によって異なります。以下はその例です。

• 適切なレベルのテストカバレッジとドキュメント（必要な場合）
• コーディング標準およびその他のコード品質要因の順守
• Playの一般的なアーキテクチャガイドラインの順守（例：Java APIとScala API間の機能パリティ）
• RFCなどの外部仕様の順守
• Playプロジェクトの方向性と理念との整合性

設計とハウスキーピングの決定

Playの設計とPlayプロジェクトの実行方法に関する議論の主な場所は、Play Frameworkフォーラムです。プロジェクトのすべての主要な新機能、リファクタリング、または変更は、最初にこのフォーラムで議論する必要があります。議論の目的は、タスクが実行されるかどうか、そしてどのように実行されるかについて理解することです。新しいトピックが投稿されたら、利害関係者は、肯定または懸念事項をコメントすることをお勧めします。

運営委員会は最終的にすべての決定について最終決定権を持っていますが、可能な限り、コミュニティの大多数のコンセンサスを得るよう努めます。

インテグレーターの選択

インテグレーターの選択は、運営委員会によって行われます。運営委員会は、以下の基準に基づいてコントリビューターにインテグレーターのステータスを提供します。

• コントリビューターはPlayに多大な貢献をしました。何が大きな貢献となるかは主観的ですが、たとえば、最近の新しいインテグレーターは、週に3つ以上のプルリクエストをレビューし、週に1つ以上のプルリクエストを行い、週に3つ以上の問題をトリアージしています。
• コントリビューターは、Playの行動規範とコントリビューターガイドラインの両方の手本となっています。
• コントリビューターは、Playコミュニティの他のメンバーから尊敬されています。
• コントリビューターは、運営委員会が以下に定めたインテグレーターのルールに同意します。

インテグレーターがPlayに定期的に貢献しなくなった場合、書き込みアクセス権が削除される可能性がありますが、Play GitHub organizationのメンバーシップは維持されます。

インテグレーターのルール

すべてのインテグレーターは、このページに概説されているプロセスに従う必要があり、Playの行動規範とコントリビューターガイドラインに関して模範となるべきです。また、以下に概説するいくつかの具体的なルールがあります。

• インテグレーターは、GitHub organizationのリポジトリに直接プッシュしてはなりません。どんなに小さな貢献であっても、すべてプルリクエストを通じて行う必要があります。これの唯一の例外は、変更のバックポートと、リリースのカットから生じる変更です。
• 一般に、プルリクエストは、playframework GitHub organizationのリポジトリにプッシュされたブランチからではなく、インテグレーターの個人フォークから行う必要があります。
• インテグレーターは、自分のプルリクエストをマージしてはなりません。すべてのプルリクエストは、別のインテグレーターによってレビューおよびマージされる必要があります。
• ドキュメントの変更は、必要に応じてリリース間でバックポートできますが、他のすべての変更は運営委員会の承認を得る必要があります。
• 問題やプルリクエストをクローズする際には、人々と接していることを忘れないでください。親切で役に立ち、正しい方向に導いてください。たとえば、誰かが質問である問題を提起した場合、問題をクローズするときに、Play Frameworkフォーラムに案内し、可能であれば質問への簡単な回答を提示してください。