Content last updated 2026-10-08

コミュニティ貢献を扱うワークフロー

Co-Create & Community Engineering チームが扱うすべてのプロセス

ワークフロー

私たちの作業計画の立て方

このチームは Contributor Success のかんばんボードを使用します。 Issue は次を満たす必要があります:

  • gitlab-org グループで作成されていること
  • Contributor Success ラベルが付いていること
  • 以下のリストから少なくとも 1 つの workflow ラベルが付いていること

私たちは priority ラベルを使って、四半期ごとの注力分野を指定します。

ワークフローラベル

  • workflow::validation backlog: Issue はまずバックログから始まり、チームが KPI、OKR、チーム戦略に対して労力と影響を検証できるようにします。
  • workflow::refinement: これらの Issue は、準備完了とマークされる前に、計画とチームでの議論を通じて検証・洗練されます。Issue は次のワークフローステージに移る前に、Implementation Plan セクションを持つべきです。
  • workflow::ready for development: これらの Issue は着手可能であり、Implementation Plan セクションと priority ラベルを持っています。
  • workflow::in dev: 今四半期に積極的に取り組んでいる Issue。
  • workflow::blocked: 現在ブロックされている Issue。説明にはブロッカーを記載し、ブロックを解除する Issue へのリンクを含める必要があります。
  • workflow::complete: 実装後に解決された Issue。これらは、クローズする前にチームおよび Developer Relations 部門へのレポートで強調すべきです。

優先度ラベル

  • priority::1（最高優先度）: 今四半期の KPI と OKR に不可欠な Issue、またはコントリビューターの作業をブロックする緊急のバグ。
  • priority::2: 今四半期の目標に沿っているが、緊急の期限がない Issue。
  • priority::3: 今四半期の目標に影響しないが、長期的な目標を支える Issue。
  • priority::4（最低優先度）: 段階的な価値をもたらすが、追加のキャパシティを待てる Issue。

Issue の選び方

チームメンバーは、workflow::ready for development から、priority ラベルに基づいて Issue を選択すべきです。 チームは今四半期の priority::1 と priority::2 の Issue に注力しますが、大きなプロジェクトの合間に優先度の低いタスクに取り組むのが理にかなう場合もあります。 私たちはタスクを選ぶ際、効率とイテレーションという GitLab のバリューに導かれ、Manager of Oneとして行動します。

レトロスペクティブ

四半期ごとに、GitLab の Issue を使って非同期のレトロスペクティブ（例）を実施します。

質問は次のとおりです:

  • 何を始めるべきか?
  • 何をやめるべきか?
  • 何を続けるべきか?

チームの DRI は、将来簡単に取り出せるよう、チームトラッカー gitlab-org/developer-relations/contributor-success/team-task に Issue を作成する責任を負います。

チームの DRI は、フィードバックを整理し、投票後に新しい四半期へ持ち込む 1 つの Issue を選ぶ責任を負います。

スタンドアップ

このスタンドアップの目的は、チームメンバー間で協力することです。これは、ブロッカーや進捗を確認し、異なる視点で考え、私たちの目標に向けてイテレーションするための、チーム固有の ミーティングです。

リアルタイムコミュニケーション

GitLab への貢献に興味がある人々のために、Discord で GitLab 貢献者ルームが利用できます。これは誰でも参加でき、コミュニティメンバーがネットワーキングし、互いに助け合うのに良い場所です。

Issue

貢献者リンク

誰もが貢献することを明確で簡単にするため、triage-ops プロセッサ が Issue に貢献者リンクを追加し、お客様/コミュニティメンバーがラベル付け、クローズ、自身への割り当てを行えるようにします。

GitLab チームメンバーではなく、ここでの初心者で、GitLab への機能、バグ修正、翻訳などの貢献を始めたいと思っていますか? 貢献者プラットフォームからオンボーディングを開始してください。

GitLab チームメンバーは、suppress-contributor-links ラベルを追加することで貢献者リンクを抑制できます。

コミュニティ貢献者向けの Issue ラベル付け

広範コミュニティの貢献を求めるに関するガイダンスと、quick win Issue の基準を参照してください。

コミュニティ Issue ワークフローの手動プロセス

部分的な Issue トリアージチェックリストを参照してください。

マージリクエスト

広範コミュニティのマージリクエストとは、https://about.gitlab.com/company/team/ に存在しない人 (任意のボット、サービスアカウントユーザー、または個人契約者を除く) が開いた MR です。

ラベル

トリアージレポート

コミュニティ関連のトリアージレポートを参照してください。

スケジュールされたワークフローオートメーション

コミュニティ関連のスケジュールされたワークフローオートメーションを参照してください。

リアクティブワークフローオートメーション

コミュニティ関連のリアクティブワークフローオートメーションを参照してください。

マージリクエストコーチ

マージリクエストコーチは、貢献者の MR を支援するために利用可能です。これには次のことが含まれます:

  • MR のレビュアーを特定する。
  • 貢献者からの質問に回答する。
  • 貢献承認基準について貢献者を教育する。
  • または、貢献者が応答しないか完了できない場合に MR を完了する。
    • その場合、coach will finish ラベルが MR に追加され、コーチは新しいコミットを直接 MR にプッシュするか、元の変更を含む新しい MR を再作成します。
    • 貢献者は MR で @gitlab-org/coaches と入力することでコーチをメンションできます。

現在のマージリクエストコーチのリストは、チームページで部門フィルタの Merge Request Coach を選択することで見つけることができます。

GitLab チームメンバーがコミュニティ貢献に関する質問がある場合は、GitLab Slack の #mr-coaching チャンネルもあります。

マージリクエストコーチに関する詳細情報 (マージリクエストコーチになる方法を含む) は、MR コーチライフサイクルページで見つけることができます。

GitLab Enterprise Edition (EE) への貢献

コミュニティ貢献者向け

GitLab Enterprise Edition の任意の有料機能に貢献するには、コミュニティ貢献者は GDK にライセンスを追加する必要があります。すでにライセンスを持っていない場合は、30 日間の無料トライアルを取得できます (Self-Managed オプションを選択)。30 日間で作業を完了できない場合は、限定数のユーザー (100) 向けに 90 日間の新しい EE ライセンスを発行できます。

このライセンスの更新:

  • 前回のライセンスサイクルでアクティブな貢献があった場合、このライセンスはさらに 1 年間更新できます。
  • 前回のライセンスサイクルでアクティブな貢献がなかった場合、90 日間の更新が許可されます。

貢献者は、ライセンスをリクエストするためにこのプロジェクトでリクエストを作成する必要があります: Wider Community Contributor License Request。

Enterprise Edition (EE) ライセンスリクエストの処理

GitLab チームメンバーが完了する必要があります:

前提条件

プロセス

  • Okta 経由で Zendesk にログイン
  • GitLab L&R Internal Requests フォームにアクセス
  • 続くドロップダウンリストから Other > Wider community license を選択
  • リクエスト Issue で提供された必須フィールドを入力
    • 連絡先情報: リクエストする貢献者の情報を使用
  • その他の必須フィールド:
    • True-up: 0
    • リクエストの優先度: Low
    • ライセンスタイプ: Ultimate (特に指定がない限り)
    • 有効期限:
      • 新規貢献者は 90 日
      • 更新は 1 年
    • 1 年更新の場合、Nick の E メールを承認マネージャーとして使用
  • 「ライセンスが発行される理由は何ですか?」で、Wider community contributor EE license request を指定し、ライセンスリクエスト Issue へのリンクを追加
  • リクエスト Issue にリクエストが提出されたことを示すパブリックコメントを追加
  • サポートフォームを送信すると、Zendesk でリクエストを「作成」するパイプラインへのリンクがユーザーに表示されます。後で調査が必要な問題があった場合に備えて、このパイプラインへのリンクを内部コメントに保存

サポートチームは、24 時間以内にこのワークフローに従って応答します。

クローズ

ライセンスがプロビジョニングされたら:

  • ライセンスリクエストがプロビジョニングされたという確認のパブリックコメントを Issue に追加
  • サポートから送信された E メールに含まれる「Private Note」のスクリーンショット付きの機密コメントを追加
  • Issue をクローズ

DCO と CLA のガイダンス

GitLab への外部貢献はすべて、貢献が行われた場所と誰の代理で行われたかに応じて、GitLab の DCO または CLA の対象となります。

組織を代理で行われたすべての貢献をカバーする包括的な企業 CLA を締結する企業貢献者向けの手順は、DCO-CLA ページに記載されています。

企業 CLA 貢献者管理

Contributor success は、Legal and Corporate Affairs チームを支援して、GitLab が企業 CLA に関連付けられたユーザーのリストを維持できる名前空間の作成と維持を行ってきました。

このグループはここで見つけることができます: https://gitlab.com/gitlab-corporate-cla

新しいグループの追加

gitlab-corporate-cla 下のサブグループは、gitlab-corporate-cla/config プロジェクトで OpenTofu を介して宣言的に管理されます。標準的なグループ設定（可視性、説明、プロジェクト/サブグループの作成レベル、Wiki 無効化、メンション無効化、share-with-group ロックなど）はすべてパイプラインによって自動的に適用されます。

  1. gitlab-corporate-cla/config に対して、groups.yaml にエントリを追加するマージリクエストをオープンします:

    - name: Acme Corp
  path: acme-corp
    1. name — 組織の正式名称（グループの表示名および標準的な説明で使用されます）。
    2. path — サブグループ用の URL セーフなスラッグ（小文字、スペースはハイフン）。
    3. description — (任意) 標準の "Approved contributors for {name} under the GitLab Corporate CLA" テンプレートを上書きします。説明に追加のコンテキストが必要な組織の場合に使用します。

  2. MR パイプラインが tofu plan を実行し、差分を投稿します。プランが想定どおり 1 つの新しいグループのみを示していることを確認してマージします。

  3. main ブランチのパイプラインが tofu apply を実行し、サブグループを作成します。安全策として、ドリフト検出が main に対してスケジュールで実行されます。

  4. apply 後の手動ステップを実行します（これらの設定はGitLab Terraform provider でまだサポートされていないため、手動で設定する必要があります）:

    1. 新しいサブグループの Settings > General > Permissions and group features で、次を設定します:
      1. Customer relations is enabled — 無効化
      2. GitLab Duo availability — Always off
    2. 組織の指定されたユーザーマネージャーのユーザーアカウントを Owner としてグループに追加します（Group information > Members の下）。
    3. ご自身のユーザーアカウントをサブグループの直接メンバーから削除します（Members の下、Membership = Direct でフィルタし、‘kebab メニュー’ をクリックして ‘Leave Group’ を選択）。

教育資料

  1. Gitpod with GDK - Introduction (ビデオ)
  2. Gitpod with GDK - Setup (ビデオ)

GitLab Notable Contributor 選定プロセス

GitLab Notable Contributor 選定プロセスを参照してください。

貢献者への感謝メッセージ

Contributor Success チームは、マージリクエストへの活発な参加について広範コミュニティメンバーに定期的に感謝してきました。 これは、次の場所での週次感謝メッセージという形を取ります:

  • discord の #thanks チャンネル。
  • フォーラムの community エリア。

MR をマージしてもらった広範コミュニティメンバーや、マージされた他の MR に参加した広範コミュニティメンバーに感謝します。

これらのメッセージは、スクリプトの助けを借りて生成されます。 スクリプトは月曜日の朝に実行されます。

トラッキング Issue:

手動実行

メッセージを手動で生成する必要がある場合は、次の前提手順に従う必要があります:

  1. toolbox プロジェクトの最新の main ブランチをチェックアウト: git clone [email protected]:gitlab-org/developer-relations/contributor-success/toolbox.git

  2. チェックアウトしたプロジェクトのディレクトリに変更: cd toolbox

  3. 必要な gem をインストール: bundle install

  4. ここの ‘wider’ の例に従ってスクリプトを実行

  5. レポートを実行する期間を必ず確認してください。

  6. 結果のメッセージを discord の #thanks に貼り付け。

  7. 貼り付けたメッセージをダブルチェックして、ユーザー/名前がすべて「正しい」ように見えることを確認。

  8. メッセージを送信して、お祝いに参加!

  9. 必要に応じて、メッセージから PI 数をトラッキング Issue に記録。

  10. トラッキング Issue の担当者と期日を更新。

イベントの組織化と宣伝

イベント計画

  • ミーティング前にアジェンダを起草します (ドキュメントがリンクのある全員に開いていることを確認してください)
    • 出欠確認、紹介
    • 各種トピック
    • コミュニティがトピックを持ち寄れるオープンフロア
  • 参加方法の手順を含めます
    • Zoom (または他のビデオプラットフォーム) へのリンク
  • イベントをDeveloper Advocacy チームカレンダーに追加します。GitLab チームメンバーでない場合は、Developer Relationsチームのメンバーにイベントをカレンダーに追加するよう依頼してください。
  • ソーシャルサポートのために以下の手順に従うか、コードコントリビューターのプランニングリポでリクエストを開きます。

ソーシャル

  • 「N 日開催の GitLab ハッカソン（リンク）に参加してください。」のような短いアクション指向のコピーを起草します。
  • イベントの少なくとも 2 週間前、1 週間前、前日に、次のチャンネルでメッセージを共有します:
    • Twitter: 自分のアカウントを使用しますが @gitlab をメンションします (注: Twitter で Zoom リンクを共有しないでください)
    • GitLab Community Discord

イベントプラットフォーム

ハッカソン

四半期ごとのハッカソンでは、GitLab コミュニティメンバーが集まり、マージリクエストに取り組み、チュートリアルセッションに参加し、GitLab Discord で互いをサポートします。ハッカソンのアジェンダ、ロジスティクス、資料、録画、その他の情報は GitLab Community Hackathon ページで利用できます。

イベントの計画は、ハッカソン Issue テンプレートに従って行われます。

バーチャルハッカソン/hackathon-in-a-box

私たちは広範コミュニティメンバーが GitLab への新しい貢献者を奨励し、サポートするためにイベントを組織化することも奨励しています。これは、対面またはバーチャル GitLab ミートアップの一部として行うことができます。

広範コミュニティメンバーがハッカソンをミートアップの一部として含めることに興味がある場合は、ミートアップ Issueを開く際にこの情報を含めるように依頼してください。Contributor Success チームメンバーがオーガナイザーに連絡し、イベントをサポートするために必要なリソースを提供します。

利用可能なリソースの一部は、hackathon-in-a-box フォルダ、GDK チュートリアルプレイリストなどで見つけることができます。プログラムマネージャーはオーガナイザーと協力して、初めて/経験の浅い貢献者に良い Issue のリストを作成し、イベント前に参加者と共有する必要があります。また、イベント中にマージリクエストを作成した人に配布できる GitLab グッズについて、オーガナイザーと連携する必要があります。

コミュニティオフィスアワー

広範コミュニティと GitLab チームメンバー間のコミュニケーションを促進するために、製品チームはコミュニティオフィスアワーをホストすることがあります。これらのオフィスアワーの目的は、製品/開発に関する広範コミュニティのフィードバックを集め、広範コミュニティの貢献を議論し、MR のバックログをレビューし、その他のトピックを話し合うことです。オフィスアワー関連の Issue または MR には、これらの例で見ることができるように、Office Hours ラベルが付きます。

通話は誰でも利用可能で、通話後に録画が投稿されます。このプレイリストで過去のオフィスアワーの例をご覧ください。コミュニティがビデオを見つけやすくするために、各ステージは独自のオフィスアワーのプレイリストを作成し、ハンドブックページからリンクする必要があります。

すべてのコミュニティオフィスアワー通話は、Developer Advocacy カレンダーと meetup.com グループに追加する必要があります。

オフィスアワー録画のセキュリティ上の注意

オフィスアワーの録画を公開する前に、認証情報や秘密情報が動画内に表示・聞き取り可能になっていないことを確認してください。これには次のものが含まれますが、これに限りません:

  • GitLab パーソナルアクセストークン（PAT）
  • プロジェクトアクセストークン
  • グループアクセストークン
  • OAuth トークンまたはクライアントシークレット
  • SSH キー
  • API キーまたは Webhook シークレット
  • パスワードまたはパスフレーズ

セッション中に誤って認証情報が露出してしまった場合は、ただちに無効化してローテーションする必要があります — ライブ配信動画の性質上、動画の編集だけに頼らないでください。

ライブストリームから変換した動画ではなく、録画を直接アップロードするチームメンバー向けには、動画を公開する前にトークンリークを検出するための GitLab 内部 video scanner が利用できます。このツールの利用は任意ですが、追加の保護レイヤーとして強く推奨されます。

録画の公開と管理に YouTube をどう活用すべきかについては、GitLab の YouTube の利用とアクセス を参照してください。

コミュニティオフィスアワー通話の組織化方法

準備

通話の実行

  • 通話のライブストリーミングについて全員の許可を求めます。次に、Zoom で「YouTube でライブ配信」ボタンを押してストリーミングを開始します。
  • アクセシビリティのために Zoom でクローズドキャプションを有効にします。
  • 通話が始まったら、「何があなたをこの通話に連れてきましたか」という質問で自己紹介のラウンドを行います。これは、コミュニティのニーズに合わせて通話を調整し、彼らの質問/期待に応えるのに役立ちます。
  • 詳細な議事録を保持します

通話後

  • YouTube ビデオを「office hour calls」プレイリストに追加します
  • Discord にまとめとビデオ録画を投稿します

コミュニティチャレンジ

(ハッカソン中だけでなく) 継続的に優先 Issue への貢献を促すため、各製品ステージに最大 5 つの優先 Issue のリストを維持し、これらの Issue について MR がマージされた広範コミュニティメンバーに賞品が贈られます。これらの Issue にはラベル Community challenge と、賞品、これらの Issue の割り当てなど、より多くの詳細が記載されます。

広範コミュニティ貢献者のサポート

広範コミュニティの貢献のブロック解除

Contributor Success チームは、広範コミュニティ貢献者のブロックを解除し、貢献を前進させるのを支援します。GitLab の他のチームがコミュニティ貢献をサポートする能力を持っていないことがありますが、これによってコミュニティの貢献を止めるべきではありません。

これら 10 個の GitLab の価値観が、広範コミュニティのブロック解除と前進を支援する努力をサポートします:

  1. 自分でやる
  2. Short toes
  3. Collaboration is not consensus
  4. 行動バイアス
  5. Disagree, commit, and disagree
  6. Escalate to unblock
  7. Cleanup over sign-up
  8. Minimal valuable change
  9. Everything is in draft
  10. Make two-way door decisions

広範コミュニティの貢献を求める

支援を求める GitLab チームメンバーは、貢献を求めて広範コミュニティに連絡することができます。より大きなプロジェクトのリクエストに移る前に、明確な実装計画を持つより小さな quick win Issue から始めることが推奨されます。

  • quick win Issue の基準に従って、Issue に quick win ラベルを追加します。
  • GitLab Community Discord の #contribute チャンネルで Issue を共有します。
  • コミュニティ貢献者が興味を示したら、彼らを Issue に割り当てます。
  • コミュニティ貢献者と連絡を取り、助けが必要かどうかを確認します。

quick win Issue の基準

GitLab は広範コミュニティに、貢献したい場合は quick win ラベルが付いた Issue を検索するようガイドしています。 これらの Issue は、コミュニティ貢献者にとってわかりやすく、貢献プロセスを学びながらもすぐに完了できるものを意図しています。 これは、誰もが貢献できるようにし、初回貢献者のコミュニティへのオンボーディングを支援するというGitLab のミッションに沿っています。

AI トリアージは、チームが作成した新しい Issue をすべて評価し、Issue が以下に該当する場合に quick win ラベルを適用します。

  • 明確で自己完結した実装計画がある（または、容易に作成できるほどわかりやすい）
  • 広範コミュニティの貢献者が迅速かつ容易に提供できる
  • コードベースに関する深い知識を必要としない

チームメンバーもこのラベルを直接適用でき、AI はその判断に同意するかどうかを評価します。 Issue が quick win に該当しないと AI が判断した場合、ラベルを追加したチームメンバーに通知します （ラベルは削除しません）。

GitLab Bot は、ラベルが 1 年以上適用されている場合、または Issue がブロックされた場合にラベルを削除します。

quick win::first-time contributor Issue の基準

オンボーディングプロセス中、新しい貢献者は quick win::first-time contributor Issue にリンクされます。これらの Issue は、私たちの最も簡単で最もわかりやすい Issue を使用して、新しい貢献者が貢献プロセスを学ぶのを助けることを目的としています。quick win::first-time contributor Issue を作成する際は、サポート連絡先を追加することが推奨されます。 各貢献者は 1 つの quick win::first-time contributor Issue のみを完了できます。最初の Issue を完了した後、貢献者は他の Issue に移るべきです。通常の quick win Issue には制限はありません。

  • Issue の説明には、貢献者が始めるのを助けるガイダンス付きの実装計画を、第二または第三レベルの見出しとして含める必要があります。 たとえば、## Implementation、### Implementation、## Implementation plan、### Implementation guide はすべて受け入れられます。 このセクションは非常に簡潔でも、Issue を解決するための可能なアクションを提供してもかまいません。
  • 少なくとも 1 人の GitLab チームメンバーまたは経験豊富なコミュニティ貢献者 (たとえば「Support contact: @username」) を Implementation plan セクションでタグ付けすることが推奨されます

初回貢献者

貢献者が GitLab 名前空間に対して初めてマージリクエストを開くたびに、ラベル「~1st contribution」が自動的にマージリクエストに適用されます。

Core Team との作業

Core Teamに関する詳細情報は、Core Team ハンドブックページで利用できます。

貢献者向け GitLab Duo

誰もが貢献できるようにするという私たちのミッションを支えるため、より広いコミュニティのすべての貢献者に、 GitLab のコミュニティフォーク全体で利用できる GitLab Duo Enterprise の無償ライセンスと GitLab Duo Agent Platform へのアクセスを提供します。 GitLab Duo は、Code Suggestions、Chat、Root Cause Analysis などの AI を活用した機能を備え、コードやパイプラインの記述と理解に必要な時間を減らすことで、 効率と有効性を高めます。 コミュニティ貢献者は、コミュニティフォークへのアクセス申請が承認されると GitLab Duo を利用できるようになります。 利用制限と期待事項は、コミュニティ貢献者向け GitLab Duo 利用ガイドラインで定めています。

コミュニティの GitLab Duo 利用量の管理

gitlab-community グループの GitLab Duo Agent Platform の利用量は GitLab Credits で計測し、ユーザーごとに上限を設けています （現在の値は利用ガイドラインを参照してください）。管理には、 gitlab-community トップレベルグループの Owner ロールが必要です。

利用量を確認するには:

  1. gitlab-community > Settings > GitLab Credits に移動するか、 グループのクレジットダッシュボードを開きます。
  2. Usage by user タブで、Total credits used により並べ替えます。上限に達したユーザーについては、Usage control status 列に Blocked usage と表示されます。
  3. ユーザー名を選択すると、Duo Agent Platform のセッション詳細へのリンクを含む、そのユーザーの個別の利用イベントを確認できます。

貢献に関連しているように見えない大量の利用について連絡するには、Duo usage コメントテンプレートを使って、貢献者の オンボーディング Issueにコメントします。 まず、その人の貢献者プロフィールと最近の マージリクエストを確認してください。

ユーザーの上限を引き上げ、引き下げ、または解除するには:

  1. グループのクレジットダッシュボードで、Credit caps を選択します。
  2. Per-user cap overrides で Add override を選択し（または既存の行を調整し）、ユーザーを選び、 上限を設定して Save を選択します。上書き設定の Enabled トグルをオフにすると、そのユーザーにはデフォルトの一律の上限が適用されます。
  3. 記録を残すため、貢献者のオンボーディング Issue に返信し、新しい上限とその理由を記載します。

ブロックされているユーザーは、上書き設定の上限が現在の利用量を上回ると、すぐにブロックが解除されます。 全ユーザーに適用するデフォルトの一律の上限も、同じページで設定します。

Duo のシートは個別には削除できません。トップレベルグループで管理され、 gitlab-community/community-members のメンバーから自動的に同期されます。コミュニティフォークのメンバーシップを維持したまま、 ユーザーによる GitLab Duo Agent Platform の利用をブロックするには、そのユーザーの上限の上書き設定を 0 にします。 コミュニティフォークから完全に削除するには、gitlab-community/community-members グループからそのユーザーを削除します。

製品ボーナスによる高価値貢献のハイライト

これは FY25Q4 (2024 年 11 月 - 2025 年 1 月) に実施する実験です。

高価値の貢献方向をハイライトするために、Contributor Success チームは、特定の期間内に自分の領域の貢献者に与えることができる、製品マネージャー (PM) 向けの専用予算を設定する場合があります。全体の予算は、ユーザー向け製品ステージ全体に均等に共有され、PM はラベル (community-bonus::100、community-bonus::200、community-bonus::300、community-bonus::500) を適用して、特定の Issue/エピックにどれだけの価値を与えるかを示すことができます。ボーナスは Issue がクローズされたときに会計され、エピックの場合、Contributor Success チームは関連する PM が議論したように、特定の Issue に対してボーナスの一部を渡すことができます。PM は Issue を選択する際、予算内に留まることが期待されます。

ボーナスは貢献後にも与えることができます。

このコンテキストでのボーナスは金銭的な助成金ではありません。これらのボーナスポイントは、貢献者ストアでの購入にのみ使用できます。

プロセス

コミュニティボーナスラベルが付いた Issue がクローズされると、トリアージレポートに表示されます。Co-Create & Community Engineering チームメンバーは:

貢献を検証する
  • Issue を訪問し、広範コミュニティ貢献者に割り当てられていることを確認します。
  • リンクされたマージリクエストが広範コミュニティ貢献者によって作成されたことを確認します。
  • 上記が明確であれば、ボーナスポイントを授与に進みます。
  • 上記が真でない場合、community-bonus:: スコープラベルを削除します。
  • 不確実な点がある場合は、Issue で関連チームに ping して確認します。
ボーナスポイントを授与する
  • https://contributors.gitlab.com/users/[GitLab username] に移動
  • Bonus Points までスクロール
  • Add points をクリック
    • 理由として Issue リンクを使用
    • ボーナスポイント数を入力
    • アクティビティタイプとして Community bonus を選択
    • Add points を選択
  • 授与したポイントが Bonus Points セクションに表示されることを確認
  • GitLab で、Issue に community-bonus-awarded ラベルを追加

クレジットカードを所有していない貢献者向け

クレジットカードを所有しておらず、手動で検証する必要がある貢献者には、 登録して サポートリクエストを発行するよう依頼します Gitlab.com user accounts and login issues の理由を使用します。

コンピュート分または他の CI/CD リソースを使い切った貢献者向け

広範コミュニティメンバーは、個人フォークから作業している場合、月次のコンピュート分を使い切ったり、他の GitLab CI/CD 制限に遭遇することがあります。

解決策は、GitLab コミュニティフォークから作業することです。

貢献者への連絡

貢献者のプライバシーを尊重するため、彼らに連絡するために公開されている連絡データのみを使用します。

貢献者に連絡する方法をいくつか紹介します:

  • GitLab ユーザー名を使用して Issue で彼らをメンションできます。
  • 私たちのコミュニケーションプラットフォーム (Discord、Slack など) を介してプライベートに。
  • ユーザーは GitLab プロフィールに E メールを持っている場合があります。場合によっては、ユーザーは他のプラットフォーム (例: GitHub) で同じユーザー名を持っており、そのプロフィールにより多くの情報がある場合があります。
  • プライベートコミット E メールを使用することを選択しない限り、E メールアドレスは git コミットに保存されます。

連絡する最良の方法を見つけたら、メンション、E メール、または Discord を使うことを選択できます。

貢献者ブログ投稿シリーズ

目標は、コミュニティの貢献者を取り上げる定期的なブログ投稿を発行することです。フォーマットはコミュニティメンバーとのカジュアルな Q&A で、GitLab ブログページに投稿されます。

ブログ投稿を開発する際は、ブログガイドラインに従ってください。

貢献者アウトリーチキャンペーン

アウトリーチキャンペーンは、貢献を停止した過去の GitLab 貢献者や、貢献に興味を表明したが始めていないユーザーと再びつながるのに役立ちます。 連絡する際、彼らの過去および/または将来の貢献を認識して、彼らの名前で GitLab forest に木を植えます。

アウトリーチの目標

Contributor Success チームは、繰り返し可能なアウトリーチキャンペーンを作成するために、3 つの目標で異なる基準とメッセージを試しました:

  1. 新しいマージリクエストを開くコミュニティメンバーを最大化
  2. キャンペーンを実行する Contributor Success の時間コミットメントを最小化
  3. アウトリーチキャンペーンが迷惑になったり、マーケティングスパムのように見えたりするのを防ぐ

復帰貢献者の候補基準

  • 過去 3 か月間に開かれたマージリクエストが 0 件
  • 過去 12 か月間に 2 件以上のマージリクエストがマージされている必要がある
  • 以前にアウトリーチキャンペーンで連絡されていない

新規貢献者の候補基準

  • 少なくとも 1 か月前にコミュニティフォークへのアクセスをリクエストして受け取った
  • 履歴にマージされたマージリクエストがない
  • 以前にアウトリーチキャンペーンで連絡されていない

結果の追跡

アウトリーチキャンペーンの結果は、アウトリーチ結果スプレッドシート で追跡され、すべてのアウトリーチキャンペーンに関するレポート Issue で報告されます。

復帰貢献者キャンペーンの結果

アウトリーチキャンペーン基準アウトリーチ総ユーザー復帰ユーザーユーザー復帰率マージ済み MR開かれた MRクローズ MR
2023 年 12 月6 か月アイドル49714.29%1102
2024 年 1 月3 か月アイドル124129.68%1522
2024 年 4 月3 か月アイドル40512.50%1211

新規貢献者キャンペーンの結果

アウトリーチキャンペーン基準アウトリーチ総ユーザー復帰ユーザーユーザー復帰率マージ済み MR開かれた MRクローズ MR
2024 年 4 月0 件の貢献27462.19%421

結果に関する観察

  • これまでのところ、復帰貢献者キャンペーンは平均ユーザー復帰率 11%、24 名の復帰貢献者、38 件のマージ済みマージリクエストで成功しています。
  • 4 月の新規貢献者キャンペーンでの実験は 2% の貢献率と低調でした。
    • このキャンペーンには、ユーザーがコミュニティフォークアクセスをリクエストしてからどれくらい前かの時間制限がなく、多くのユーザーがおそらく始めることへの興味を失っていました。
    • 復帰貢献者は、マージリクエストを開く点で新規貢献者よりも成功しやすいことが予想されます。
  • 開かれたマージリクエストとマージされたマージリクエストの結果に加えて、Issue でのユーザーエンゲージメント、オンボーディングタスクの完了、植樹への感謝を観察しました。
  • 多くの貢献者は、これらの結果に表示されるためにアウトリーチから 1 か月以内にマージリクエストを作成する空きがないでしょう。キャンペーンは、後で貢献する機会の前向きなリマインダーになる可能性があります。

アウトリーチキャンペーンのスケジュール

アウトリーチキャンペーンは 3 か月ごとに実行することを目指していますが、貢献者を引き付ける可能性のある発表と一致させる必要があります。 たとえば、今後のハッカソンや、GDK-in-a-box のような新しい貢献機能を発表します。

アウトリーチキャンペーンのワークフロー

候補プールのレビュー

Contributor Success チームは、次のものを削除するために候補プールをレビューします:

  • GitLab アカウントまたは個人アカウントのいずれかを持つ既知の GitLab チームメンバー
  • 失効したが、キャンペーンの外で別途連絡される必要がある長期貢献者 (例: Core メンバー、元 MVP、GitLab Heroes など)
  • 行動規範違反があった、連絡されたくない、または GitLab に貢献したくないと表明した既知のコミュニティメンバー

Issue を作成して木を植える

アウトリーチ Issue への対応とクローズ

  • アウトリーチ Issue で質問に回答するか、フィードバックを認識します
  • 2 か月後にクローズメッセージで Issue をクローズし、貢献者が Issue を再オープンしてサポートが必要な場合は連絡するよう促します

潜在的なイテレーション

  • ロール基準または除外候補リストに対して候補をチェックすることで、自動化により手動レビューステップを削減
  • アウトリーチキャンペーン後に貢献するユーザーをそれぞれの Issue で感謝し、戻ってきた理由を共有する機会を与える

貢献者の表彰

ハイライトされた貢献への感謝

時々、広範コミュニティメンバーが特に優れた貢献を提出します。任意の GitLab チームメンバーまたは広範コミュニティが、彼らを Notable Contributor として推薦するプロセスに従うことができます。

年間トップ貢献者

定期的な貢献者を認識するため、各暦年のトップ貢献者のリストが Top Annual Contributors ページ に公開されます。トップ貢献者には 3 つのカテゴリがあります:

  • SuperStar: 75 件を超えるマージ済み MR
  • Star: 11 件から 75 件のマージ済み MR
  • Enthusiast: 5 件から 10 件のマージ済み MR

これらの貢献者向けにカスタマイズされた GitLab グッズが作成され、Printfection で利用可能になります。GitLab チームメンバーは、以下の手順に従って広範コミュニティメンバーに賞を送ることができます。

  1. 1Password の認証情報を使用して Printfection にログインします。
  2. Campaigns の下の Giveaways に移動し、新しい GIVEAWAY CAMPAIGN を作成します (複数のアイテムを含めたい場合は、Merchandise タブの下に新しい Kit を作成する必要があるかもしれません)。
  3. アイテム/キットをキャンペーンに追加します。
  4. 各貢献者用の Giveaway リンクを生成します。
  5. 個別の E メールに Giveaway リンクを含めて Top Annual Contributors に送信します。

貢献者ライフサイクルセグメント

GitLab コードコントリビューターコミュニティを理解、サポート、エンパワーする取り組みにおいて、次のライフサイクルセグメントを考えました。

これらのライフサイクルセグメントは個々のユーザーレベルで割り当てられます。

貢献者の経験レベルマージ済み MR
Level 00 MR
Level 11 - 3 MR
Level 24 - 25 MR
Level 326 - 75 MR
Level 475+ MR
貢献者ステータスマージ済み MR期間
カジュアル貢献者< 10 MR過去 6 か月
通常貢献者10+ MR過去 6 か月
リーディング貢献者20+ MR過去 6 か月
Core選挙ベース全期間

貢献者コミュニティをセグメント化することで、貢献者がこのファネル全体でどのように「移動」しているか、そして彼らのジャーニーを通じてどのようにサポートできるかをよりよく理解できるようになります。

目標は、貢献者をサポートし表彰する方法を特定することにより、すべてのセグメント (非アクティブセグメントを除く) でコードコントリビューターを増やすことです。

貢献者メトリクス

注: これは現在、貢献者メトリクスを収集できるすべての場所の作業リストです。これはまだ貢献者プログラムの成功をモニタリングするために使用するメトリクスの最終セットではありません。

Tableau ダッシュボード

社内では、GitLab はさまざまな KPI のパフォーマンスを追跡するために Tableau を使用しています。以下は、コミュニティ関連ダッシュボードのリストです。

ダッシュボード説明
Wider Community Dashboard貢献者 (人) と組織に関連するメトリクス
MRARR DashboardGitLab の顧客でもある貢献組織に関連するメトリクス

GitLab.com

gitlab.com 上のプロジェクト (たとえば CE、EE、Omnibus、Shell など) の Merge Requests ページからデータを直接クエリし、マイルストーン、ラベルなどに適切なフィルタを適用することもできます。例の一部は、以下のメトリクステーブルに記載されています。

貢献者数

過去には、この例で見られるように、GitLab コミュニティ (GitLab チームメンバー + 広範コミュニティ) の 2,000 以上の貢献者をしばしば言及していました。しかし、これには古い https://contributors.gitlab.com ページに基づいて、CE および EE プロジェクトへの貢献者のみが含まれていました。

他の GitLab プロジェクトを含めると、貢献者の総数ははるかに多くなります。

  • 総コードコントリビューター: GitLab チームメンバーと広範コミュニティ貢献者を含む (2015 年以降)

  • 広範コミュニティコードコントリビューター: 広範コミュニティ貢献者のみを含む (2015 年以降)

  • これらの数値は、マージリクエストがマージされたか、クローズされたか、まだオープンかに関係なく、少なくとも 1 つのマージリクエストを開いた貢献者をカウントします。

  • 成功した貢献 (マージリクエストがマージされた) を持つ広範コミュニティコードコントリビューターの数は、Wider Community Dashboard を見ることで見つけることができます。

  • 広範コミュニティメンバーの定義の更新については、トップ誤用語ページを参照してください。

GitLab の貢献者数について人々が尋ねたとき、彼らが総コードコントリビューターまたは広範コミュニティコードコントリビューターについて尋ねているかを明確にするのが最善です。ほとんどの場合、人々は広範コミュニティの数により興味を持つ傾向があります。

Contribute to GitLab ガイドに記載されているように、コード以外にもコミュニティが GitLab に貢献する方法があることに言及することも重要です。翻訳、エバンジェリズム、フォーラムでのサポート、開かれた Issue などの貢献は、上記のメトリクスには含まれていません。

モニタリング対象のプロジェクト

私たちは gitlab-org グループのさまざまなプロジェクトでの貢献を監視・表彰しており、GitLab プロジェクトだけではありません。

一般的なルールとして、プロジェクトは gitlab-org グループのマイルストーンと Community contribution ラベルを使用している場合、広範コミュニティ貢献を監視するためにセットアップされます。

モニタリング対象の gitlab-org グループプロジェクトの網羅的なリストを参照してください。

GitLab への貢献に興味がありますか? 利用可能な貢献機会はこちらで確認してください。

最終更新 October 28, 2026: Merge pull request #591 from kyama0/translation/batch-2026-10-28-1 (5d840611)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License