Developer Relations

GitLab Developer Relations ハンドブックへようこそ

DevRel とは？

Developer Relations（略: DevRel）は、テクノロジー、コミュニティ、アドボカシーが交わる地点で活動し、より広いテック界における GitLab の声であり耳となっています。そのコアミッションは、開発者、コントリビューター、ユーザーで構成される活気ある、エンゲージメントの高いコミュニティを育み、維持することにあります。これには、教育コンテンツの作成、イベントやワークショップの開催、プログラムの開発、知識交換とコラボレーションのプラットフォームの提供を含む多面的なアプローチが含まれます。チームは GitLab の機能と能力をプロモートするだけでなく、コミュニティからのフィードバックを積極的に聞き、製品開発と改善に反映するために組み込んでいます。

私たちのミッションとビジョン

Developer Relations は、GitLab の顧客を支援し、コミュニティを通じてつながり、開発者がいる場所でエンゲージすることで、プラットフォームの認知と採用を推進します。GitLab は GitLab.com だけで毎月 3000 人を超える開発者とエンゲージし、毎月 250 件以上の貢献を受けています。これにより、DevSecOps 領域でのユニークな影響力を持ち、イノベーションの加速に貢献しています。私たちの究極的な目標は、クラス最高の技術的なイネーブルメントとアクティブなコントリビューターコミュニティを通じて、開発者の心と頭を勝ち取ることで、GitLab の認知度を高め、顧客の成功を推進することです。

Developer Relations では、私たちのミッションとビジョンを会社の 3 年戦略と整合させています。私たちは 誰もが貢献できる と信じています。GitLab がこのゴールを達成できるよう、アウトリーチとエンゲージメントを倍増し、コミュニティでのプレゼンスを強化し、健全なコントリビューターコミュニティをサポートすることを目指しています。最終的に、これらのゴールは認知度、採用を高め、私たちのデュアルフライホイールを駆動します。

私たちの戦略

私たちの運用戦略は内部ハンドブックに記載されていますが、ビジネスの機微性、顧客への影響、そしてチームメンバーにとっての心理的安全な環境を促進するため、機密として分類されています。以下では、より広いコミュニティに公開されており、Developer Relations チームがコラボレーションを歓迎している戦略的計画を見ることができます。

• Contributor Program Unification & Growth Plan
• Co-Creation Initiative

チーム紹介

Name	Role
Arianna Haradon	Senior Fullstack Engineer
Cesar Saavedra	Senior Developer Advocate
Colleen Lavin	Developer Advocate
Daniel Helfand	Developer Advocate
Fatima Sarah Khalid	Senior Developer Advocate
Fernando Diaz	Senior Developer Advocate
Itzik Gan-Baruch	Sr. Developer Advocate, Product Management internship
John Coghlan	Director, Developer Advocacy
Lee Tickett	Principal Fullstack Engineer, DevRel Engineering Core Team member
Mattias Michaux	Fullstack Engineer, DevRel Engineering
Michael Friedrich	Principal Developer Advocate
Missy Davies	Fullstack Engineer, DevRel Engineering
Nick Veenhof	Director, DevRel Engineering & Programs
Raimund Hook	Staff Fullstack Engineer, DevRel Engineering
Sina Abadi	Fullstack Engineer, DevRel Engineering
William Arias	Senior Developer Advocate

連絡方法

チャットで連絡する

• Developer Relations のチームメンバーは 2 つの Slack チャンネルを利用しています:
  • #developer-relations: すべての GitLab 関連のディスカッション用（例: Issue に関する質問、近日開催のイベントの告知）
  • developer-relations-confidential: （非公開）GitLab 外の人がいるチャンネルで共有できない機密トピックのディスカッション用（例: チーム内で #company-fyi-private で共有されたトピックの議論）
• Slack アクセスを持つ GitLab チームメンバーやその他の人は、#developer-relations Slack チャンネルにアクセスするか、@devrel-team グループハンドルにタグ付けすることで、私たちに連絡できます。
• より広い GitLab コミュニティのメンバーは、公開 Discord ルーム で私たちとつながることができます。

Developer Relations 内のチームには、以下の Slack チャンネルでアクセスできます:

• #developer-advocacy: Developer Advocate チームは、コンテンツの更新、ソートリーダーシップと製品アイデアを共有し、コミュニティ対応や CFP などをサポートします。
• #developer-relations-programs: Developer Relations Programs に関するすべての問い合わせ用
  • #developer-relations-engineering: Developer Relations Engineering に関するすべての問い合わせ用
  • #developer-relations-community-contributions: コミュニティ貢献に関するディスカッション用
  • #developer-relations-eng-and-programs: Developer Relations Engineering と Programs 間のクロスチームディスカッション用

メールで連絡する

• 各プログラム固有のメールアドレス をご利用ください

Issue を作成する

私たちは GitLab を利用して計画、コラボレーション、実行を行っています。どこで、どのように Issue を作成できるかについての詳細は、私たちのオペレーショナルワークフローページに記載されています。

• Developer Advocacy
• Developer Relations Programs

緊急連絡先

• Developer Relations 緊急連絡先
• インシデント管理の役割
• インシデント／インフラ関連の Slack チャンネル: #incidents、#infrastructure_platforms

私たちの働き方

Developer Relations チームのリソース

• Programs リソース
• Meetup チェックリスト

私たちのハンドブック

• Developer Relations Engineering
  • Contributors Program
• Developer Advocacy
• Developer Relations Programs
  • Open Source
  • Education
  • Co-Create

私たちのワークフロー

コミュニティエンゲージメント:

• Code of Conduct Enforcement
• Community Response プロセス
• Events

コミュニティプラットフォーム:

• Discourse Forum
• Discord
• Reddit
• StackOverflow
• Common Room

コンテンツ:

• Content Effectiveness 戦略

• コンテンツレビュー / Fix Fridays

• UTM トラッキング戦略 組織:

• チーム予算

• Swag オペレーション

• ライセンス付与

• Workato automation

• Email

• Twitter/X

• クラウドリソース

Community Interest

会社、製品、または価格設定に関する変更に取り組んでおり、それらが GitLab コミュニティのメンバーや GitLab ブランドに重大な影響を与えることが予想される場合は、~Community Interest ラベルを使用することをお勧めします。これにより、Developer Relations チームが計画プロセスにおいて、より広い GitLab コミュニティの利益を代表できます。

Developer Relations チームのすべてのメンバーは、gitlab-com と gitlab-org の両方のプロジェクトでこのラベルをサブスクライブする必要があります。

チームのタッチポイント

私たちのチームには、つながりを保ち、私たちの仕事に整合性を持たせるために使用しているいくつかの週次イベントがあります:

• チームミーティング（隔週）
  • チームミーティングは Zoom で録画され、録画はミーティングノートの対応する日付にリンクされます。
• 各チームメンバーとそのマネージャー間の 1:1 ミーティング。
• 各チームメンバーが Slack の Geekbot 経由でチェックインする質問。回答は #developer-advocacy-hangout Slack チャンネルで共有されます。
  • 月曜日（週末のソーシャル、その週の予定）
  • 木曜日（達成、思考、ブロッカーなどを共有するためのリマインダー）
• 週末更新: 結果と勝利。Google Drive で Developer Relations - End of Week updates を検索してください。

私たちのカレンダー

私たちは集合的な通知のため、また、チームのロジスティクスとイベントを管理するために、チーム全体のカレンダーを使用しています。さらに、Developer Relations 内の特定のチーム（Developer Advocacy チームカレンダーなど）は、自分たちのプログラム固有のカレンダーを維持している場合があります。

• Developer Relations Team
• Community Events
• Developer Advocacy Team

Developer Relations KPI

Developer Relations チームは、いくつかの主要パフォーマンス指標と関連パフォーマンス指標をモニタリングしています。

1. Unique Wider Community Contributors per Month (target: Above 200 contributors per month) 🔗
2. Wider Community merged MRs per release 🔗
3. Developer Relations Monthly Outreach
4. Active Community Members
5. GitLab for Education Quarterly Active Seats
6. MRARR (target: Identified in Tableau Chart) 🔗

チームロゴ

GitLab Developer Relations チームのロゴは、Google Drive で gitlab-devrel-logo を検索することで .png および .svg 形式で見つけることができます。

チーム予算

詳細は Developer Relations 予算ページ で確認できます。

コミュニティの多様性、インクルージョン、ベロンギング

GitLab のコアバリュー「Diversity, Inclusion, and Belonging（DIB）」に沿い、Developer Relations チームは、プログラムとオペレーションのすべての側面に DIB を意図的に組み込もうとしています。GitLab および広い GitLab コミュニティで DIB を育むことを目指しています。

DEI 戦略

オープンソースコミュニティにおける DEI（Diversity, Equity and Inclusion）の味方として、GitLab の Developer Relations チームは、コントリビューターコミュニティ内で以下の DEI の取り組みを行うことをコミットしています:

• DEI プロジェクトのバッジ付け:
  • コミュニティ全体のイニシアチブと連携し、バッジシステムを通じて DEI の取り組みを認識、サポート、プロモートする仕組みを確立します。
  • GitLab のプロジェクトの DEI 価値とインクルージョンの取り組みをハイライトします。
  • GitLab でホストされているオープンソースプロジェクトに同じことを行うよう奨励します。
• 初めてのコントリビューターのインクルージョン:
  • エクスペリエンスを学び、改善するために、初めてのコントリビューターに関するユーザーリサーチ研究を実施します。
  • 初めてのコントリビューターの視点からドキュメントを改善します。
  • 新規参加者のためのコミュニティオンボーディングを改善します。
• DEI グループへの参加:
  • Developer Relations チームから始めて、GitLab チームメンバーの DEI グループ参加を追跡します。
  • チームメンバーがオープンソース DEI ワーキンググループとイベントに参加することを奨励します。
  • 四半期ごとにチームメンバーをポーリングし、参加を追跡します。
  • Developer Relations から Marketing、そして GitLab 全体に拡大します。
• 適格なイベントでの Swag／コントリビューターポイントクーポン:
  • 適格なイベントで GitLab Swag と GitLab コントリビューターポイントクーポンを提供します。
  • クーポンコードでコミュニティメンバーと潜在的なコントリビューターにインセンティブを与えます。
• GitLab コントリビューターリソースグループ:
  • GitLab の Team Member Resource Groups（TMRG）と類似した GitLab コントリビューターリソースグループを形成します。
  • メンタリング／コーチングの機会を含めます。
  • 非貢献の開発者向け、または Developer Relations チームメンバー向けのグループを検討します。
  • 指定された過小評価されているグループ向けのイベント / デー開催を検討します。

イベントとアクティビティの計画

このセクションは、Developer Relations チームと GitLab チームがイベントやアクティビティを計画するときに覚えておくべきヒントとベストプラクティスを文書化するためのものです。

• 画像: 私たちは、ユーザー、顧客、コミュニティメンバーの多様なグループを表す画像の使用を促進しようとしています。多様な表現の不足を見た場合は声を上げ、可能なときはそれらの画像の更新を積極的に支援します。
• スピーカー: イベント主催者および参加者として、GitLab が主催または関与するイベントに多様なスピーカーを含めようとしています。
• オープンマインドであること: 現在のポリシーについて積極的にフィードバックを求め、オープンマインドを保ちます。変化に開かれており、チームと広い GitLab コミュニティで DIB を育み続けるために構造的な変更を行う意思があります。
• 成長マインドセットを保ち、学び続けること: コミュニティで DIB を育む方法や、自分たちがインクルーシブである方法を学ぶための記事を読み、ワークショップやトレーニングに参加します。
• 多様なコミュニティメンバーがリサーチに参加することを奨励すること: プロダクトのインクルーシビティが重要であり、コミュニティのためだけでなくコミュニティと一緒に構築する必要があると認識しています。
• GitLab Diversity Scholarship プログラムを推進すること: この奨学金は、Diversity, Inclusion, and Belonging に焦点を当てたイベントを金銭的に支援します。

私たちに刺激を与えるコミュニティ

私たちは他のコミュニティが行っている素晴らしい仕事から刺激を得ています。刺激を得ているコミュニティの一部:

• Linux Foundation - 重要なオープンソース技術の管理者として機能する、大規模でエンゲージメントの高いコミュニティ。
• CNCF - 重要なオープンソース技術の管理者として機能する、大規模でエンゲージメントの高いコミュニティ。
• FINOS - 重要なオープンソース技術の管理者として機能する、大規模でエンゲージメントの高いコミュニティ。
• Debian - 重要なオープンソース技術の管理者として機能する、大規模でエンゲージメントの高いコミュニティ。
• GNOME - 重要なオープンソース技術の管理者として機能する、大規模でエンゲージメントの高いコミュニティ。
• KDE - 重要なオープンソース技術の管理者として機能する、大規模でエンゲージメントの高いコミュニティ。
• Fedora - 重要なオープンソース技術の管理者として機能する、大規模でエンゲージメントの高いコミュニティ。
• Drupal - 重要なオープンソース技術の管理者として機能する、大規模でエンゲージメントの高いコミュニティ。
• Wikimedia Foundation - 自由な情報の推進者であり、大規模でエンゲージメントの高いコミュニティを持つコミュニティ。
• Kubernetes - ユーザーグループとチャンピオンの大規模なネットワークで構成され、互いの成長と Kubernetes のより良い活用を支えます。
• AWS - ユーザーグループとチャンピオンの大規模なネットワークで構成され、互いの成長と AWS のより良い活用を支えます。
• Dev.to - 技術コミュニティ、特に新規参加者がコンテンツを学び共有するための歓迎される場所を作ります。
• Hacker News - 最新の技術ニュースやトレンドについての活発な議論で知られるコミュニティ。
• Google Summer of Code - 技術コミュニティをより多様でインクルーシブにし、技術に新しい人々へ新しい機会を作る取り組みを通じて刺激を与えます。
• Outreachy - 技術コミュニティをより多様でインクルーシブにし、技術に新しい人々へ新しい機会を作る取り組みを通じて刺激を与えます。
• Grace Hopper Community / Systers - 技術コミュニティをより多様でインクルーシブにする取り組みを通じて刺激を与えます。
• Lesbians Who Tech - 技術コミュニティをより多様でインクルーシブにする取り組みを通じて刺激を与えます。
• Techqueria - 技術コミュニティをより多様でインクルーシブにする取り組みを通じて刺激を与えます。
• Latinas in Tech - 技術コミュニティをより多様でインクルーシブにする取り組みを通じて刺激を与えます。
• Women in Tech - 技術コミュニティをより多様でインクルーシブにする取り組みを通じて刺激を与えます。
• Women Who Code - 技術コミュニティをより多様でインクルーシブにする取り組みを通じて刺激を与えます。
• Rails Girls - 技術コミュニティをより多様でインクルーシブにする取り組みを通じて刺激を与えます。

Community Learning Pathway

Community Learning Pathway は、Developer Relations チームの働き方、さまざまなコミュニティプログラム、GitLab への貢献方法をコミュニティに伝えるために作られたコースです。コースを完了したコミュニティメンバーと GitLab チームメンバーはバッジを獲得します。

Community Building Reading Group

Community Building Reading Group は、GitLab でコミュニティを構築することに関心がある、または関与している GitLab チームメンバー向けです。Developer Relations チームのメンバーが主催するこの学習重視のグループは、コミュニティを想像し、設計し、構築し、育み、成長させ、支援することに関するさまざまな原則と実践を検討します。学習と議論の潜在的なトピックには以下が含まれます:

• コミュニティ活動を主導し実施する
• 新しいコントリビューターを歓迎する
• コミュニティ内およびコミュニティとの関係を管理する
• コミュニティの権威と権力関係を調整する
• コミュニティの行動規範を設計し適用する
• コミュニティ文化を育む
• コミュニティの健全性と成功を測定する
• コミュニティ参加者をコミュニティコントリビューターへ変える
• コミュニティメンタリングを促進する
• コミュニティ主導のイノベーションとビジネスモデルを構築する
• コミュニティのインフラストラクチャとガバナンスモデルを評価する
• コミュニティの価値提案と交換を理解する

このグループの一員としてコラボレーションすることで、メンバーは次を目指します:

• 技を磨く。 コミュニティと働くには、思慮深く熟練した実践が必要です。このグループは、メンバーがより良い実践者になるのを助ける資料を共同でレビュー、評価、学習する場を提供します。
• 支援と成長の場を作る。 コミュニティと働くには感情労働が必要であり、それに取り組む人々は、同じ志を持つ協力者と仕事上の課題を話し合う場から恩恵を得ることがよくあります。このグループはそのような場の 1 つとして機能します。
• リソースを生成し共有する。 コミュニティと働くことは、ベストプラクティスと信頼できるフレームワークの知識があると容易になります。最先端に関する資料を読みレビューすることで、メンバーは他の人がアクセスし学べる知識共有の場を生成します。

コミュニティ構築の実践に関心のある GitLab チームメンバーは誰でも、このグループに参加し貢献できます。典型的な GitLab ブッククラブ とは異なり、このリーディンググループは:

• 個別で期限のあるイベントではなく、継続的な取り組みです
• 単一の作品ではなく、一連の作品に焦点を当てています

リーディンググループは、グループメンバーが一緒に決める頻度で運営されます。グループメンバーは、毎週扱う資料、例えば書籍の章、ホワイトペーパー、調査レポート、プレゼンテーション録画、ケーススタディも共同で決めます。

1. グループメンバーは、Developer Relations チームの Community Building プロジェクト で reading-group テンプレートを使って Issue を作成し、Reading Group::Proposed ラベルを付けることで、グループが学習し議論する資料を提案します。
2. グループメンバーは互いの提案を閲覧し、学習対象を共同で選択できます。
3. 読むものを決めたら、Issue を Reading Group::Up Next. に再ラベル付けします。
4. 提案された資料の読書と学習を始めたら、Reading Group::Now Reading ラベルを適用して Issue を再ラベル付けします。
5. 選択した資料を終えたら、関連する Issue に Reading Group::Finished ラベルを適用します。プロジェクトボード がすべての選択を追跡します。

読みながら、グループメンバーは Community Building プロジェクトに保存されたファイルを通じてメモと所感を非同期に共有します。選択した資料を完了したら、これらのメモを磨き、Community Building Wiki を更新します。

各サイクルでは、グループメンバー（通常は資料を提案した人）が「リーダー」として行動します。グループリーダーは、グループの読書を導き、議論を枠付ける基本的な議論の質問または思考を促す洞察を提示します。グループメンバーは、読書資料についてライブで同期的な議論を行うため、定期的な間隔で集まります（議論ミーティングの推奨時間: 45 分）。これらのミーティングの録画は利用できますが、議論には個人的な詳細やセンシティブな問題が含まれることが多いため、録画は内部 Google Drive 経由で GitLab チームメンバーのみがアクセスできます。

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