新しい WordPress ソフトウェアのリリースは、何百人もの貢献者の協力とサポートによってのみ成功できる重要な作業です。
その作業は何ヵ月にも及ぶこともあり、グローバルプロジェクトのあらゆる分野に関わります。各リリースは、さまざまな側面のオーナーシップを持つ活動的な貢献者のグループによって管理されます。このグループは、特定のソフトウェアバージョンの「リリースチーム」として知られています。リリースチームは、アイデアや解決策を結び付け、リリースを可能な限り効果的なものにするために、すべてのチームを横断して調整します。
各リリースチームのメンバーは、さまざまな経歴やスキルを持っています。彼らは WordPress ソフトウェアとコミュニティだけでなく、オープンソースの Web 開発についても十分に理解している必要があります。さらに、コミュニケーションスキルとプロジェクト管理スキルも持っています。
このページでは、リリースに関わるさまざまな役割と、それに関わるタスクの種類について説明します。
リリースチーム
リリースチームの主な役割は、リリースの開始から立ち上げまでをリードすることです。そのため、メンバーはコネクターやファシリテーターとして、ボトルネックや問題を解決する必要があります。
新しいリリースは、ソフトウェアのすべての部品に影響を与えます。新しく導入された、または修正された機能は、潜在的に以下の可能性があります:
- 既存のプラグインに影響を与える
- プラットフォームのフロントエンドとバックエンドの両方のアクセシビリティに影響を与える
- など沢山あります。
そのため、リリースチームにはあらゆる専門分野の代表者を置くことが重要です。それぞれが特定の側面に責任を持ち、プロセス中の支持者として行動します。
さらに、すべての変更を完全にドキュメント化することが重要です。これは、すべての関係者が参加することにも役立ちます。
開発サイクルの過程で、リリースチームには何百人もの貢献者が参加します。これらの貢献者は、リリースチームのメンバーや他の経験豊富な貢献者の指導を受けながら、さまざまなタスクに取り組みます。
これまで、すべてのリリースにプラットフォームのあらゆる分野の代表者が含まれていたわけではありません。マイナーリリースでは、すべてのチームの関与は必要ないかもしれません。よく見られるリリースチームの役割を以下に示します。
リリースチームの役割
あらゆる状況をカバーするために、理想的には、リリースの各リードには少なくとも2人が必要です。
共有の責任
これらは、以下の特定の役割のためにドキュメント化されたタスクと責任ですが、リリースサイクル全体を通して誰でも引き受けることができます。
- 可能な限り公の場でコミュニケーションをとる (チケット、コンポーネントチャット、Make/Core 投稿など)。
- 進捗を妨げるものを特定し、仲間、チームリード、リリースリードに助けを求める。
- 期限を守る。
- ドキュメント、HelpHub の記事、複数のコミュニティとの調整が必要な開発者ノート、マーケティングなど、他のコミュニティとの連携が必要な変更を特定する。
- 自分のチームのチケットやタスクに焦点を当てたバグスクラブを実施する。
- チーム間のディスカッションを促進し参加する。
- 常にテストすること !
リリースリード
責任
- リリースの全体的な目標を設定する
- 機能プラグインのマージに関する最終決定を下す
- リリースを発表するニュースブログ記事の最終確認を行い公開する
- リリースのジャズミュージシャンを選ぶためにマットと調整する
リリースコーディネーター
責任
- 毎週の開発チャットの要約を公開する
- 毎週の開発チャットを #core で実行する
- Slack でさまざまなリリースプロセス (ベータ、リリース候補、リリース) を実行する
- さまざまなマイルストーンのためのブログ記事を書く
- ハンドブックの期限に注意し、関係するさまざまなチームに連絡を取る (プラグイン、テーマ、Polyglots などに通知を送る)
- 期限を知らせる
- ハンドブックに記載されている手順をメモし、必要であれば変更を提案する
- 必要であれば、チーム間の議論を促進する
- 危険信号、ブロッカー、またはチームに必要な追加支援のために、俯瞰的に見渡す
コアトリアージリード
責任
- バグスクラブを実行する
- リリースコーディネーターが不在のときに開発チャットを実行する
- リリースコーディネータと一緒に Slack でさまざまなリリースプロセスを実行する (ベータ版、リリース候補版、リリース版)
- リリースのマイルストーンでチケットのトリアージを試みる
- チケットの優先順位付けを行い、すぐに取り掛かる必要がある緊急性の高い問題に対してグループ内で注意喚起を行い、迅速な解決を図る
- コンポーネントメンテナーとのコミュニケーションを図り、より多くのリソースや注意が必要な箇所を把握する
コアテックリード
責任
- パッチやチェンジセットの実現可能性、コードの品質、技術設計、コーディング規約への準拠をレビューする。全体的なソフトウェアアーキテクチャーに従っていることを確認する
- 要求または必要に応じて「セカンドオピニオン」と技術的なガイダンスを提供する
- すべての貢献者がリリースサイクルのフェーズに従っていることを確認する。たとえば、例外が提案され、プロジェクトリーダーによって承認されない限り、ベータ版の間は機能強化を行いません
- ベータ、RC、最終リリースの各プロセスが、技術面で可能な限りスムーズに実行され、すべてのリリース手順が完了していることを確認する
- この役割は、新機能や機能強化、(大規模な) バグ修正が間に合わない場合、ケースをエスカレーションし、意思決定を支援する責任もあります。たとえば、新機能がベータ版までに100%完成していない場合や、コードがまだ「アルファ」品質でさらに作業が必要な場合、その機能を進めるか、次のリリースで追加するかを決定するために、レビューを促進し、より多くの情報を収集します。このようなケースは、通常プロジェクトリーダーにエスカレーションされます
コアデザインリード
責任
- 主要な Trac チケットのデザインアイデア、ガイダンス、モックアップを提供する
ドキュメントの調整
責任
- 開発者ノートを必要とするリリース内の変更点を追跡する
- 変更点を最もよく理解しているチケットの参加者 (コミッター、コンポーネントメンテナー、チケットを所有する貢献者、担当者) と調整し、開発者ノートの下書きを作成する
- すべての開発者ノートが、(リリース候補1と同時に発行される) フィールドガイドの前に、校正、レビュー、公開するために十分な時間をかけて作成されていることを確認する
- チケット参加者が開発者ノートを書けない場合、書いてくれる人を見つけるか、自分で書く
- 新機能に必要なドキュメントページがリリース前に作成されていることを確認する
- リリースの変更履歴を書き、HelpHub に公開する
- Codex の WordPress バージョンページを更新する
ドキュメントのレビュー
責任
- ドキュメント調整チームから提供される開発者ノートを校正・レビューする
- コード例を確認する
- 追加の例を提案する
- 開発者ノートが問題、解決策を正確かつ徹底的に記述し、変更点の適切な使用方法を特定していることを確認する
MarComms (マーケティングおよびコミュニケーション) リード
責任
- リードと協力して、アップグレード後の WordPress 管理画面に表示されるアバウトページの下書きを作成する
- リードと協力して、WordPress.org ニュースブログのアナウンス記事の下書きを作成する
- この役割のタスクに関する包括的なガイドはこちらです
エディターテックリード
責任
- どの Gutenberg の機能がリリースに含まれるのか、含まれるべきなのかを大まかに定義する
- パッチやプルリクエストのトリアージとレビューを行い、RC のテスト、ブロックエディターのミーティングを調整する
- すべての Gutenberg に関する機能とバグ修正が、各コアベータ版、RC の前に予定通りに行われるようにする
- 各リリースで修正が必要な Gutenberg の重要なバグやリグレッションのリストを集める。貢献者がこれらのバグと重要性を理解できるようにする (プロジェクトボード)
- Trac チケットを通して、Gutenberg とコアの同期・更新を手伝う
- Gutenberg の props が適切に収集されていることを確認する
- Gutenberg のリリースノートが期限内に公開されるようにする
- リリースチームの残りのメンバーと次の点についてコミュニケーションをとる:
- リリースおよび各コアベータ、RC に含まれる Gutenberg からの更新をドキュメント化する
- マーケティングチームとアバウトページのために、重要な機能とアップデートを強調する
- 他のリードと調整を行う
- Gutenberg のアップデートが、できるだけバグが修正されたうえでコアリリースに予定どおりに含まれ、適切に伝達されるようにする
エディタートリアージリード
責任
- エディターに関する項目にフォーカスしたバグスクラブを実行する。
- Gutenberg GitHub リポジトリに送られてくるチケットをレビューし、適切なリリース固有のプロジェクトボードに必要なものを追加するなど、さらなるレビューのために項目が適切にラベル付けされていることを確認する。
- コアエディターのテックリードとコミュニケーションをとり、より多くのリソースや注意が必要な箇所を把握する。
- リリースサイクルを通して重要な問題に優先順位をつけ、緊急性の高い問題が迅速に解決されるようにする。
この作業はコアテックリードとの協力と調整によって行われるため、より詳細で実践的な内容についてはブロックエディター メジャーリリース時のリリースプロセスを参照してください。
エディターデザインリード
責任
- 主要なブロックエディターチケットに関するデザインアイデア、ガイダンス、モックアップを提供する
アクセシビリティリード
責任
- リリースの優先順位を設定し、アクセシビリティに関する一般的な範囲を定義する
- リリースの主な優先順位にない他のすべてのチケットをトリアージし、優先度や重要度にもとづいて選択する
- アクセシビリティのバグスクラブを計画し実行する (アクセシビリティに焦点を当てたスクラブを週に1回行う)
- さまざまなコンポーネントのチケットに貢献し、Trac と Gutenberg GitHub リポジトリの両方でアクセシビリティフィードバックを行う
- アクセシビリティ関連のドキュメントを作成し、必要に応じて Make/Core (開発者ノート) や HelpHub で公開する
- リリースの範囲を計画通りに進めるために、デザインチームやメディアチームと調整する
- リリースプロセス全体を通じて、すべてのコンポーネントのアクセシビリティに関する潜在的なリグレッションに対処するために、Trac/GitHub 上でチケット/issue を開く
- Make/Accessibility やコア開発者チャットで、リリースの範囲や進捗状況を伝える
- パッチが確実で、レビューされ、期限内にコミットされるようにする
- コード、テスト、スクリーンショット、デザインレビューなどでチケットパッチに貢献する
- アクセシビリティに関連したレビューと貢献を行い、アクセシビリティ標準が満たされていることを確認する
パフォーマンスリード
責任
- リリースの優先順位を設定し、パフォーマンスフォーカスの一般的な範囲を定義する。水平的な影響 (「どれだけのサイトに適用されるか ?」) と垂直的な影響 (「適用されるサイトのパフォーマンスをどれだけ向上させるか ?」) の両方を判断する
- 主な優先事項から外れたマイルストーンのチケットを定期的にトリアージし、報告者と関係する他の貢献者にフォローアップする
- 優先度、重要度、必要な労力と時間、貢献者の可用性、サイクルの残り時間にもとづいて、現在のリリースサイクルで特定のチケットの修正をコミットすることの実現可能性を評価する
- 定期的なパフォーマンスバグスクラブやその他のパフォーマンス関連ミーティングに参加またはリードする
- 以下に挙げる項目を主な対象として、Trac や Gutenberg 内の、さまざまコンポーネントの関連するプルリクエストやパッチのパフォーマンスを、事前に、そして必要に応じてベンチマークする:
- リリース予定の新機能または API
- パフォーマンスの向上を目的とした機能強化や修正
- 測定可能なパフォーマンスへの影響 (ポジティブかネガティブかにかかわらず) を示唆する別の変更
- チームメンバーと協力して、パフォーマンス測定のベストプラクティスが守られ、明確に伝達されるようにする
- WordPress コアパフォーマンスダッシュボードを定期的に監視し、潜在的なパフォーマンス低下を特定し、根本的な変更がコミットされた関連チケットに報告する
- 他のリリースリード、主にコアテックリードとエディターテックリードと調整し、パフォーマンスガイダンスで優先事項をサポートする
- リリースリードの Slack チャンネルやコア開発者チャットで、リリースの範囲や進捗状況を伝える
- ドキュメンテーションリードと協力して、ベータフェーズの前または初期に、パフォーマンス関連の開発者ノートの投稿をタイムリーに公開する
- パフォーマンス関連のチケットに貢献しているチームメンバーをサポートする。たとえば、トリアージ、フィードバック、コードレビュー、ベンチマーキングを支援するチームメンバーの調整や、コミュニケーションやドキュメント関連タスク (WordPress のコアドキュメントの強化や開発者ノートの執筆) のガイダンスなど
- チケット、プルリクエスト/パッチ、テスト、パフォーマンスベンチマーク、コードレビューなどへの貢献を調整する
デフォルトテーマ
新しいデフォルトテーマは、今年の最後のリリースにバンドルされます。この作業には多くの役割が必要です。
デフォルトテーマデザイン
責任
- デフォルトのテーマデザインのドラフトを作成し、それらのドラフトを繰り返し、最終候補として選択されたデザインに磨きをかける
- Make Core/Make Themes ブログでデザインを紹介する
- プロセスを通して、必要に応じてデザインを更新する
- #core-themes でのミーティングに参加する (時にはリードする)。
- 主にフロントエンドで重要な点に関して、コードでテーマに貢献する
- テーマの機能と動作をドキュメント化し、(issue やプルリクエストの) 開発ガイドと WordPress.org のサポートページに掲載する
- 主にデザイン関連の issue やプルリクエストをレビューする
デフォルトテーマ開発
責任
- デフォルトテーマのデザインリードによって作成された主要なデザインの実装をリードする
- デフォルトテーマのデザインリードからのデザインの実装を支援する他のユーザーに、技術的なガイダンスとレビューを提供する
- テーマ内のバグを見つけたときは issue やプルリクエストを作成する
- issue や プルリクエストをラベルで整理する
- #core-themes で毎週新しいデフォルトテーマのミーティングを行う
- 重複する issue や、タイムラインの範囲外であったり、#core-themes チームによって却下された issue をクローズする
- issue やプルリクエストをレビューし、必要に応じて「コミット」マークをつける
- (同じリリースでビルドされる新しいデフォルトテーマ以外の) デフォルトテーマのチケットをマイルストーンで承認し、レビューし、必要に応じてチケットを延期する
- 新しいデフォルトテーマの開発を管理し、関係者全員がタスクと短いスケジュールに集中できるようにする
- リリースの各フェーズでテーマディレクトリにアップロードするテーマをパッケージ化する
デフォルトテーマの調整
責任
- すべてのデフォルトテーマが、現在のリリースで追加された新機能を完全にサポートしていることを保証する (適切と判断された場合)。
- Trac の バンドルテーマコンポーネントでチケットをトリアージする
- チケットを管理し、何が準備できていて、何が準備できていなくて、何が含まれるべきでないかを決定する
- チケットがテストされ、準備ができたと確認されたときに、チケットに「コミット」マークを付ける
- 新しいデフォルトテーマのデザイナーや開発者とコミュニケーションを取り、新しい機能のサポートを追加する際に共通のアプローチを使用する
サポート
責任
- リリースサイクルのフェーズ2～4の間は、WordPress.org のサポートフォーラムに参加し、アルファ/ベータ/RC フォーラムに注目する
- そこで報告された潜在的な問題を、適切なリリースチームメンバーに知らせる
- 返信のない投稿への返信を手伝う
- 英語以外の言語を話す場合は、英語以外のサポートフォーラムのリストをチェックして、サポートを提供する
- フォーラムによくある質問がある場合は、新しいユーザードキュメントページを作成できるように、リリースチームに知らせる
テスト
責任
- ベータリリース、リリース候補、最終リリース、そして可能であれば毎日の trunk/ナイトリービルドのテストを増やすための取り組みを調整し、リードする。
- テストへの取り組みや機会を拡大する。手伝いたいと考えている人たちのオンボーディングを手伝ったり、特定の機能のテストのためのラウンドアップ投稿を行う。
- できる限りテストミーティングに参加して、テストの優先順位をコミュニティに伝える。
- チームと協力して、新機能や大きな変更に必要なテストを確実に行う (例: ギャラリーブロックのリファクタリング)。
- できるだけ多くの人が参加できるように、テストに関するドキュメントを改善する。
上記のセクションでは、各コアチームの作業やリリース開始に向けた作業ではなく、リリースチームの役割について説明しています。Make チームが現在のリリースサイクルにどのように貢献しているかについては、開発ブログをご覧ください。