デベロッパーアドボケイトチームのワークフロー

チームのワークフロー

デベロッパーアドボケイトチームのワークフローページへようこそ。チームがどのように機能し、チームと協力する方法を学びましょう。私たちは主に Developer Advocate Meta issue tracker を使用しています。チームラベル developer-advocacy とその他のラベルを所有しており、これらは gitlab-com グループレベルにあります。私たちのチームが追跡するために、必要に応じてこのグループ配下の任意の Issue にラベルを追加できます。

概要ビデオ

ワークフロー概要ビデオでは、ワークフローのさまざまなコンポーネントを詳細に紹介しています。ワークフローで表示される機密 Issue があるため、ビデオは社内のみです。ビデオの特定の章にジャンプしたい場合は、以下のリンクを参照してください。

ビデオの章:

• はじめに
• Issue の作成
• ラベル概要
• Issue ボード
• Issue トリアージと DevRel-Bot ルール

デベロッパーアドボカシーチームの働き方

チームのすべてのアクティビティは、デベロッパーアドボカシー Meta プロジェクト、またはチームが連携する他のチームの Issue tracker で Issue として追跡されます。アクティビティは、コンテンツ、イベント、その他のアクティビティの 3 つのカテゴリに分類されます。Issue の作成を容易にするため、チームは関連するプレースホルダとラベルが事前入力された Issue テンプレートを使用しています。Issue テンプレートとそのショートリンクへの直接リンクは次のとおりです。

Issue ボード

Issue ボードはデベロッパーアドボカシーチームのアクティビティに関する単一の信頼できる情報源です。デベロッパーアドボケイトには、Issue ボードの列を期日順に並べておくことが求められます。これは、デベロッパーアドボカシーチームの作業を追跡するためにボードを使用するステークホルダーに役立ちます。

注: このページのすべてのショートリンクは https://campaign-manager.gitlab.com/campaigns/view/114 で管理できます。

デベロッパーアドボケイトチームとの協力方法

会話を始めるには、Issue を開くのが最良の方法です。developer-advocacy ラベルは gitlab-com グループレベルにあり、グループ構造内の任意の Issue またはマージリクエストに追加できます。

developer-advocacy ラベルは必須ですが、その他のラベルはオプションです。DevRel-Bot またはチームメンバーがトリアージを行い、必要なラベルを追加します。コメントのノイズを減らすため、DA-Type::Consulting と関連する Consulting チームラベルは自分で追加してください。

デベロッパーアドボケイトリクエスト Issue テンプレートを使ってリクエストを送信できます。リクエストをトリアージするために必要な情報を収集するためのガイドが提供されています。

CFP

Call-for-Papers (CFP) のワークフローは、CFP ハンドブックで整理されています。

ラベル

デベロッパーアドボケイトチームのワークフローはラベルでサポートされており、Issue のタイプ、ステータス、その他の関連情報を判断するのに役立ちます。チームの主要なラベルは developer-advocacy です。チームが所有する、参加する、または認識する必要があるすべての Issue は、developer-advocacy でタグ付けする必要があります。その他のラベルは以下のとおりです:

一般ラベル

Issue 管理

一般ワークフローラベル

デフォルトのフローは ToDo -> Doing -> (OnHold) -> Done です。FYI の Issue は別のチームが所有し、別のワークフローを通過するため、どのワークフローも通りません。

コンテンツワークフローラベル

コンテンツ固有のワークフローには次のラベルを使用します:

Issue タイプ

これらのラベルは、Issue で文書化されたアクティビティのタイプを識別するのに役立ちます。これは、時間がどこで費やされ、適切な DRI を割り当てるかをチームが理解するのに役立ちます。

コンテンツタイプ

DA-Type::Content が選択された場合、コンテンツのタイプを識別する DA-Type-Content ラベルが必要です。

コンサルティングラベル

他のチームからデベロッパーアドボケイトに対する、所有、参加、またはアクティビティに協力するというリクエストはコンサルティングとして分類され、これらのリクエストは通常、依頼するチームに基づいてラベル付けされます。これらは、デベロッパーアドボケイトチームが頻繁に協力する社内のチームです。彼らのラベルは次のとおりです:

• DA-Consulting::Alliances
• DA-Consulting::CorpComms
• DA-Consulting::CorpEvents
• DA-Consulting::Community
• DA-Consulting::Engineering
• DA-Consulting::FieldMktg
• DA-Consulting::GrowthMktg
• DA-Consulting::Product
• DA-Consulting::Sales

これらのラベルは、Issue が DA-Issue-Type::External と DA-Type::Consulting を持つ場合、チームラベル developer-advocacy と DA-Status スコープラベルとは別に必要です。あなたのチームがリストにない場合でも、リクエストを送信でき、適切にトリアージされます

コンサルティング用に作成された Issue は、チームの四半期予算に対してカウントされます。詳細はリクエスト予算セクションで学べます。

リージョンベースラベル

これらのラベルは、Issue またはアクティビティに関連付けられたリージョンを識別するために使用されます:

ボットラベル

これらのラベルは、トリアージ目的で DA-Bot によって自動的に割り当てられます。

CFP ラベル

これらのラベルは、CFP 提出のワークフローを追跡するために使用されます。

トリアージラベル

これらのラベルは、レビューが必要な Issue を識別するために DevRel ボットによって使用されます。

その他のラベル

Issue トリアージ

DevRel-Bot は、ラベルの適切で一貫した使用を確保するため、GitLab Triage プロジェクトを使用しています。ボットはまた、ラベル使用に基づく Issue のトリアージにも役立ちます。ボットが現在使用しているポリシーは次のとおりです:

CFP ワークフロー

CFP ワークフローは、上記で説明した CFP ラベルに基づいています。

start
: CFP, CFP::Upcoming;
: CFP, CFP::Open;
if (CFP submissions) then (yes)
    : CFP, CFP::Submitted, CFP-Submitted::{0..7};

    if (CFP is Accepted) then (yes)
        : CFP, CFP::Accepted, CFP-Accepted::{0..7};
    else (no)
        : CFP, CFP::Closed;
    endif;
elseif (No submissions) then (missed)
    : CFP, CFP::Closed;
else  (cancelled)
    : CFP, CFP::Cancelled;
endif
stop

クイックアクションを使用した CFP ワークフローの例:

1. 提出を計画している、またはすでに提出した場合:

   1. 新しい CFP Issueを作成します。
   2. Issue テンプレートはすでに ~"CFP" ~"CFP::Open" ラベルを設定しています。
   3. 期日を CFP 提出期日に設定します。

2. 1 つのトークを提出した:

   1. ラベルを ~CFP-Submitted ~CFP-Submitted::1 に変更します
   2. 複数のトークを提出した場合は、~CFP-Submitted:: スコープラベルを正しい数を反映するように調整します。
   3. Issue の submissions セクションを更新します。可視性のために Issue にコメントします。

   /label ~CFP-Submitted ~CFP-Submitted::1
   

3. CFP がクローズされた後、CFP::Closed ラベルを設定し、期日を Issue にリストされている CFP 通知日に更新します。

   /due <cfp notification date>
   

4. CFP の通知が来て、少なくとも 1 つのトークが受理された。

   1. ラベルを ~CFP-Accepted ~CFP-Accepted::1 に変更します
   2. 複数のトークが受理された場合は、~CFP-Accepted:: スコープラベルを調整します。
   3. 可視性のために、トークタイトルを Issue にコメントします。
   4. 期日をイベント日に設定し、すべての登壇者が割り当てられていることを確認します。

   /label ~CFP-Accepted ~CFP-Accepted::1
   

5. イベントが終わったら、フィードバックと結果で Issue を更新します。

   1. 既存のものがあれば、トークのビデオを YouTube プレイリストに追加します。
   2. Issue を DA-Status::Done としてマークし、クローズします。

   /label ~DA-Status::Done
   /close
   

トークが受理されなかった場合、上記の Issue をクローズするだけです。

CFP が提出なしでクローズされた場合、CFP::Closed ラベルを追加します。CFP の提出が計画されていたが、別の決定がなされた場合、CFP::Cancelled ラベルを追加します。

リクエスト予算

バーンアウトを防ぎ、リクエストに適切に優先順位を付け、コミットしたリクエストを成功裏に提供できるよう、私たちのチームは社内のステークホルダーのために予算を作成しました。これらの予算は、チームメンバーが GitLab にとって最高優先度のニーズに対応できるよう、リクエストに優先順位を付けることを奨励しています。

これらのリクエストタイプは、次のカテゴリに分類されます:

1. イベントリクエスト
2. CFP リクエスト
3. コンテンツリクエスト

私たちの目標と OKR をサポートするチーム主導のコンテンツ作成や登壇機会、リリースサポート、Hacker News を含むソーシャルメディアモニタリングなど、進行中のアクティビティはチーム予算にカウントされません。

イベントリクエスト

イベントリクエストには、イベント参加 (例: 顧客ミーティングへの参加、イベントのスタッフ、ディナーやソーシャルイベントへの参加、ニュース用イベントのモニタリング) と、デモやプレゼンテーションなどのイベントでの登壇機会の両方が含まれます。

CFP (Call for Proposals) リクエスト

CFP リクエストには、デベロッパーアドボケイトにイベントやメディアの機会の提案を提出するよう依頼することや、オープン CFP に提出するチームメンバーをサポートすることが含まれます。

企業、フィールド、またはパートナーイベントの CFP にデベロッパーアドボケイトを提出依頼するには、デベロッパーアドボケイトに CFP の提出を依頼するを参照してください。

コンテンツリクエスト

コンテンツリクエストには、ブログ記事、ポッドキャスト、メディアインタビュー、またはデベロッパーアドボケイトをメディアの機会に参加させるリクエストが含まれます。

リクエストのスコアリング

以下のリストの各チームには、リクエスト用に四半期ごとに 15 ポイントが割り当てられています:

あなたのチームが上記にリストされていない場合は、私たちの空き状況に基づいてリクエストを処理します。

リクエストの管理

このプロセスは、コンテンツリクエスト、ウェブキャスト、インタビュー、ミートアップなど、あらゆるリクエストをカバーします。プロセスには次のことが含まれます:

• 依頼者は、各チームの予算消費を追跡できるよう、自分のチームを識別するラベルと予算スコアに対応するウェイトを割り当てる必要があります。
• デベロッパーアドボケイトチームのメンバーが Issue をトリアージし、必要なすべての詳細と指示を提供します。
• リクエストにアクションが取られると、必要なラベルが Issue に適用されます。
• リクエストが完了すると、Issue は依頼者に再度割り当てられ、Issue がクローズされる前に、結果として生成された必要なメトリクスを提供します。

ページのソースコードを見る - ページの編集 - please contribute.