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