Issue Triage

GitLab は Open Development を信じており、GitLab.com 上のプロジェクトに対してコミュニティが Issue を立て、マージリクエストを開くことを推奨しています。コミュニティのコントリビューションは貴重であり、私たちはできるだけ効果的に対応すべきです。その中心にあるのがトリアージ、すなわちタイプと深刻度に応じた分類のプロセスです。

どの GitLab チームメンバーでも Issue をトリアージできます。トリアージされていない Issue の数を少なく保つことはメンテナンス性にとって不可欠であり、私たちの集団的な責任です。他の責務の合間に Issue をいくつかトリアージするか、定期的にそのための時間を確保することを検討してください。

部分トリアージ

現時点では、グループラベルのない Issue を手動でトリアージするための十分なキャパシティがありません。 私たちは、タイプとグループのラベルを適用するために、セルフトリアージと AI トリアージの組み合わせに依存しています。

部分トリアージのチェックリスト

• Issue がスパムである場合:
  • Issue を報告する。
  • Issue を confidential にする。
  • #abuse Slack チャンネルに Issue へのリンクを投稿する。
• Issue がヘルプのリクエストである場合:
  • サポートメッセージを投稿し、Issue をクローズする。
  • あるいは、追加情報を求めて ~“awaiting feedback” ラベルを適用する。
• Issue が重複である場合:
  • 重複メッセージを投稿する。
  • /duplicate アクションを呼び出して元の Issue へのリンクを作成し、Issue をクローズする。
• タイプラベルを割り当てる。
  • Issue がバグなのかサポートリクエストなのか不明確な場合は、グループの PM/EM をタグ付けして意見を求める。
• ~"type::bug": 深刻度ラベルを割り当てる。
  • ~“severity::1” または ~“severity::2” の場合: グループの PM/EM をメンションする。
• グループラベルを割り当てる。
  • 適切なグループラベルがない場合: ステージ（“devops”）ラベルを割り当てる。
  • Issue が今後 18 か月以内の解決を計画されている場合は ~"backlog::prospective label" を割り当てる。それ以外の場合は ~"backlog::no-commitment" を割り当てる。
• 任意で、関連するドメインエキスパートをタグ付けする。

完全トリアージ

以下の基準がすべて満たされたとき、Issue は完全にトリアージされたとみなされます。

• 部分的にトリアージされている。
• マイルストーンが設定されている。
• ~"type::bug"、~"Deferred UX"、または ~"backlog::triage" ラベルが付いた Issue には、優先度ラベルが適用されている。

タイプラベル

タイプラベルは Engineering Metrics ページで定義されています。 タイプについて不明な場合は、グループのプロダクトマネージャーまたはエンジニアリングマネージャーをタグ付けして意見を求めることができます。

グループラベル

グループラベルを割り当てると、gitlab-bot が正しいステージとセクションのラベルを自動的に割り当てられるようになります。 Features by Group の一覧は、正しいグループを見つけるのに役立ちます。

優先度

優先度ラベルは、Issue の重要性を示し、スケジューリングを導くために使用されます。優先度ラベルは、市場の状況、プロダクトの方向性、IACV への影響、影響を受けるユーザー数、チームのキャパシティに基づいて設定されることが期待されます。優先順位付けの DRI はワークタイプに基づいて決まります。

深刻度

深刻度の見積もりに助けが必要な場合は、#s_developer_experience チャンネルで連絡してください。

注: これらの深刻度の定義は Issue のみに適用されます。インシデントの深刻度の詳細については、Severity Levels セクションを含む Incident Management ページを参照してください。

深刻度ラベルは、緊急性を判断し、~"type::bug" および ~"type::maintenance" がユーザーに与える影響を明確に伝えるのに役立ちます。1 つのタイプには複数のカテゴリがあり得ます。

バグの場合、バグカテゴリラベル ~"bug::availability"、~"bug::performance"、~"bug::vulnerability"、~UX の存在は、そのカテゴリの深刻度の定義を使用することを示します。~"type::bug" が複数のカテゴリに対応する場合、適用すべき深刻度はより高いものにすべきです。例えば、Issue が ~"bug::availability" で ~"severity::2"、~"bug::performance" で ~"severity::1" を持つ場合、その Issue に割り当てる深刻度は ~"severity::1" にすべきです。 メンテナンス Issue の場合、~"backlog::triage" の存在は、深刻度の定義を指定しなければならないことを示します。

Issue の深刻度を決定したら、なぜその深刻度を選んだのかを要約して説明するノートを追加してください。これにより、将来のチームメンバーがあなたの根拠を理解し、Issue への対処をどのように進めればよいかがわかります。

すべての ~"type::bug" Issue には、以下のいずれかが必要です。

1. 6 か月ごとの更新を伴う ~"backlog::prospective"。該当する場合は SLO を過ぎてもオープンのままである理由の正当化を含む。
2. 正当化を伴う [~"backlog::no-commitment"](https://gitlab.com/groups/gitlab-org/-/epics/18639)。
3. 修正なしでクローズされる理由の正当化。

深刻度 SLO

深刻度ラベルは、以下のラベルが付いた Issue の完了時間を定義するのにも役立ちます。

• ~"type::bug"
• ~"type::maintenance"
• ~"infradev"

これは、私たちの SLO 目標を測定するために使用される、期待されるタイムラインと緊急性を示します。

深刻度レベルの例

Issue が 2 つの深刻度ラベルの間に入るように見える場合は、より高い深刻度ラベルを割り当ててください。

• ~"severity::1" の例
  • データの破損/損失。
  • セキュリティ侵害。
  • Issue またはマージリクエストを作成できない。
  • Issue またはマージリクエストにコメントやスレッドを追加できない。
  • メッセージが本来は情報提供であるべきところで、（ブロッカーのように見える）エラーメッセージが表示される。
  • UI 内の不明確な指示が不可逆的な変更につながる。
• ~"severity::2" の例
  • Web IDE を通じて変更を送信できないが、コマンドラインは機能する。
  • マージリクエストページのステータスウィジェットが機能していないが、テストパイプラインページで情報を確認できる。
  • 回避策は利用可能だが、Rails console の使用が必要で、受け入れがたいほど複雑である。
• ~"severity::3" の例
  • Issue ページからではなく、Merge Requests のリストビューからのみマージリクエストを作成できる。
• ~"severity::4" の例
  • 不正確な色。
  • 位置のずれ。

クローズされた Issue の再評価

Issue のトリアージ担当者として、あなたは後で浮上する追加情報に基づいて自分の判断を調整する責任があります。 そのためには、自分がクローズした Issue のその後の活動を追跡し、必要に応じて判断を調整してください。

Availability

~"bug::availability" ラベルが付いた Issue は、GitLab SaaS（GitLab.com または GitLab Dedicated Tenant）の可用性に直接影響します。これは ~"type::bug" の別のカテゴリとみなされます。

Incident Management の目的のために、インシデント Issue の深刻度は以下の availability 深刻度マトリックスに基づいて選択されます。

私たちは、顧客のビジネス目標と日々のワークフローへの影響に基づいてこれらの Issue を分類します。

優先順位付けスキームは、セキュリティと可用性の作業が機能の速度よりも優先される、私たちのプロダクト優先順位付けに準拠しています。

これらの深刻度ラベルの存在は、主にユーザーへの影響を考慮することによって、標準の深刻度ラベル（~"severity::1"、~"severity::2"、~"severity::3"、~"severity::4"）を修正します。これらの Issue の深刻度は、GitLab.com ユーザーへの影響の再分析に応じて変わる場合があります。

(1) - 軽減は、ホットパッチ、重要なコードと構成の変更など、非標準の作業プロセスを使用します。Infrastructure 部門が所有し、利用可能なエスカレーションプロセス（dev-escalation など）を活用します。

(2) - 解決は、コードレビューなど、標準の作業プロセスを使用します。スケジューリングは、定義された SLO 目標の範囲内で Product 部門が所有します。

Availability の優先順位付け

Availability Issue の優先度は、以下のように深刻度に結びついています。

マージリクエストエクスペリエンス

マージリクエスト (MR) エクスペリエンスは、私たちの製品の中核です。多くのチームが MR ワークフローのコンポーネントにコントリビュートしているため、ちぐはぐな体験になってしまっています。

重複は主に以下の領域で見られます: Merge Request Widgets、Mergeability Checks、MWPS、Merge Trains。

Transient Bug ワーキンググループでの分析の一環として、最も影響を受けている上位の製品領域は以下であることがわかりました。

1. create::code review
2. verify::continuous integration
3. create::source code（同率）
4. plan::project management（同率）

これらの製品グループは GMAU への感度も高いです。これらの製品グループは、マージリクエスト機能と重複するバグに対する認識を高めることで恩恵を受けます。

マージリクエストエクスペリエンスの優先順位付け

この領域では、アクションへの意識を高める必要があります。バグがマージリクエストエクスペリエンスに関連する場合は、~UX ~merge requests ラベルを付けるべきです。 優先度は、以下のように深刻度に結びついています。

ブロックされたテスト

実行されないエンドツーエンドのテストは、予期しない可用性の問題を引き起こす可能性がある盲点につながります。 私たちは、隔離されたエンドツーエンドのテストを引き起こす Issue を迅速に解決することで、カバレッジが安定してアクティブであることを確保しなければなりません。

Blocked tests の優先順位付け

エンドツーエンドのテスト実行をブロックするバグへの認識を促すため、新しく開かれた ~test ~“type::bug” Issue は、いくつかの Slack チャンネルでアナウンスされます。

• エンドツーエンドのテスト実行をブロックする新しく開かれたバグはすべて、#quality チャンネルでアナウンスすべきです。
• エンドツーエンドのテスト実行をブロックする、製品バグである新しく開かれたバグは、適切な EM と PM をタグ付けして、#development と #vp-development チャンネルでもアナウンスすべきです。

優先度は、以下のように深刻度に結びついています。

Performance

パフォーマンスの改善: 意図したレスポンスタイムに 1 イテレーションで到達することはできないかもしれません。 私たちは、パフォーマンスの改善を分割することを推奨します。できるところで改善し、新しいレスポンスタイムに基づいて次の適切なレベルの深刻度と優先度を再評価してください。

UX

UX バグ

一部の UX 関連の Issue は、私たちのシステムユーザビリティスケール (SUS) スコアに影響することが知られており、これは私たちの3 か年戦略における焦点です。私たちは特に bug::ux ラベルが 付いた Issue を対象とします。これらの Issue には深刻度ラベルが適用され、type::bug Issue の深刻度と SLOに従います。

Deferred UX

~Deferred UX とラベル付けされた Issue にも、付随する ~"type::bug" ラベル なしで 深刻度（さらに優先度）ラベルが適用されます。Deferred UX は、改良が必要なユーザー向け機能を、後続のイテレーションで改善する意図を持ってリリースするという決定から生じます。これは意図的な決定であるため、~Deferred UX は ~"severity::3" より高い深刻度を持つべきではありません。なぜなら、MVC は明白なバグや重大なユーザビリティの問題を意図的に持つべきではないからです。~"severity::3" より高い Deferred UX Issue を作成していることに気づいた場合は、その Issue を MVC に再び組み込むことについてステージグループのチームと話し合ってください。

Transient bug

transient bug（一時的なバグ）とは、同じアクションに対して常に発生するわけではない、予期しない意図しない動作です。

transient bug は、ユーザーがアクションを取ったときに何が起こっているのかについて矛盾した印象を与え、一貫して発生しないことがあり、短期間しか続きません。これらのバグはユーザーのワークフローをブロックしないことがあり、通常はページ全体の再読み込みで解決されますが、ユーザーエクスペリエンスに悪影響を与え、製品への信頼の欠如を生み出す可能性があります。ユーザーは、自分が見ているデータが古いのか、新しいのか、アクションを取った後に更新されたのかさえも不確かになる可能性があります。一時的な動作の例には以下が含まれます。

• 「Apply Suggestion」ボタンをクリックしても、適用された提案でページが更新されない
• クイックアクションを使って Issue のマイルストーンを更新したのに、サイドバーが新しいマイルストーンを反映するように更新されない
• マージリクエストをマージしたのに、マージリクエストページがまだ「Open」と表示される

Issue を「transient bug」として定義するには、~"bug::transient" ラベルを使用してください。

Infradev Issue

infradev Issue は、GitLab.com または Dedicated でインシデントが発生し、レスポンダーがこの Issue がこの種の将来のインシデントの発生を防げると判断したときに作成されます。

Issue には infradev ラベルが付けられることがあり、これは Infradev Engineering Workflow で詳述されているように、SaaS の可用性と信頼性に関連する専用のプロセスをサブスクライブすることを意味します。これらの Issue は、確立されたバグの深刻度 SLOに従います。

infradev Issue は、gitlab-org/gitlab、gitlab-com/gl-infra/production-engineering、gitlab-org/gitaly、gitlab-com/gl-infra/platform/runway/team を含むいくつかのプロジェクトにまたがって存在できます。すべてのオープンな infradev Issue は、どのプロジェクトに存在するかにかかわらず、SaaS Health Dashboard で表示できます。履歴の傾向と分布は、Tableau Infradev Dashboard で利用できます。

Limit 関連のバグ

GitLab は、ほとんどの大規模アプリケーションと同様に、特定の機能内で制限を強制します。制限がないことは、セキュリティ、パフォーマンス、可用性に影響を与える可能性があります。このため、制限に関連する Issue は ~"bug::availability" サブカテゴリの ~"type::bug" とみなされます。

Issue を制限に関連するものとして定義するには、~"availability::limit" と ~"bug::availability" ラベルを追加してください。

深刻度は、以下の表を使用して評価すべきです。

これらの Issue は、確立されたバグの深刻度 SLOに従います。

Issue のトリアージ

初期トリアージには（最低限）Issue に適切にラベルを付けることが含まれます。これにより、ラベルのない Issue を検索することで、トリアージされていない Issue を見つけることができます。

以下のいずれかのリンクをたどってください。

• GitLab
• GitLab Omnibus

Issue を 1 つ選び（リストの最も古いものを優先します）、以下の Issue トリアージのプラクティスを念頭に置きながら、批判的な目で評価してください。自問すべき質問をいくつか挙げます。

• Issue が説明していることを理解できますか？
• どのラベルが当てはまりますか？特にタイプ、ステージ、深刻度のラベルを考慮してください。
• どれくらい重大に見えますか？プロダクトやエンジニアリングのマネージャー、またはセキュリティチームにエスカレーションする必要がありますか？
• ~"bug::vulnerability" ラベルが適切でしょうか？
• confidential にすべきでしょうか？通常、~"bug::vulnerability" Issue や、私的な情報を含む Issue の場合がそうです。

適切と思われる各ラベルを適用してください。セキュリティへの影響がある Issue は特別に扱うべきです。security disclosure process を参照してください。

Issue が不明確に思える場合 — どのラベルを適用すべきか確信が持てない場合 — は、リクエスト者に事情を明確にするよう求めてください。 常に私たちのユーザーコミュニケーションガイドラインを念頭に置き、トリアージを完了するのに十分な情報を得るまで会話を続けることを約束してください。

Issue がまだ有効かどうかを検討してください。特に古い Issue では、~"type::bug" が報告されてから修正されている場合や、~"type::feature" がすでに実装されている場合があります。

他の Issue やマージリクエストからのクロスリファレンスノートを必ず確認してください。それらは情報の素晴らしい源です！ 例えば、クロスリファレンスされたマージリクエストを見ることで、「Picked into 8-13-stable, will go into 8.13.6.」と表示されているのを確認できる場合があり、これはその Issue がバージョン 8.13.6 以降で修正されていることを意味します。

Issue が要件を満たしている場合、スケジューリングリクエストを行うことが適切かもしれません。あなたの判断を使ってください！

完了です！Issue にはすべての適切なラベルが付いており、バックログ、クローズ、スケジューリング待ち、またはリクエスト者からのフィードバック待ちの状態になっているかもしれません。時間があれば、別のものを選んでください。

Issue トリアージのプラクティス

私たちは、triage-ops で @gitlab-bot ユーザーを使い、いくつかのポリシーを自動的に強制しています。 自動トリアージの詳細については、Triage Operations を読んでください。

とはいえ、すべてを自動化することはできません。このセクションでは、手動で行っているプラクティスのいくつかを説明します。

Shared responsibility issue

時々、どのグループやステージが責任を持つべきかを選ぶのが難しい Issue に遭遇することがあります。これらの Issue は、製品の Shared Responsibility Functionality と呼ばれるものに対処している可能性が高いです。

これらへのアプローチは、分散型のトリアージプロセスを使用することです。トリアージは単一のレポートやリストに集中化されておらず、それらの Issue をレビューする責任が 1 人の個人やグループに課されることもありません。これは、継続的に進行するベースで（定期的なスケジュールイベントではなく）この共有責任カテゴリに該当する可能性のある多数の Issue に対処するために、私たちのトリアージ業務をスケールさせるのに役立ちます。

目標は、グループレベルのリーダーシップ（すなわち Product Manager および/または Engineering Manager）が、これらの Issue を誰が、いつ、どのように対処すべきかについて決定する力を持てるようにすることです。より上位のマネジメントの個人やグループは、競合する優先事項のために行動方針を決定するのが難しいときに、エスカレーションに対処し、決定を下すためのバックアップとして機能します。

初期トリアージ

これらの Issue の 1 つをトリアージしている場合は、作成後できるだけ早く Issue にグループラベルを割り当てるよう最善を尽くしてください。完璧である必要はありませんが、その Issue に取り組むのに最も適したグループを特定するために意識的な努力をしてください。

グループを選ぶときに、以下の質問を自問できます。

• そのグループは、自分のプロダクトカテゴリにこの領域を直接挙げていますか？
• そのグループは、当該 Issue の基盤となる技術を扱っていますか？
• 過去に同様の作業をしたことがありますか？
• 同様の横断的な機能に定期的に関与する、基盤的なグループですか？
• 影響を受けるファイルを特定し、git blame を使って最後の変更の作者を確認できますか？
• そのファイルの Code Owner を特定できますか？

可能なグループのリストを最初に絞り込むのに役立てるため、Product Categories ページや Stage Groups Ownership Index ページをレビューするとよいでしょう。

いずれにせよ、必要に応じて作者にフォローアップの質問をすることで Issue の性質を理解しようと試み、その後、要件を、必要なスキルや専門知識に最もよく一致するグループにマッピングすべきです。

二次トリアージ

二次トリアージは、Issue がすでにグループに割り当てられており、そのグループ内の誰か（通常は PM または EM）が優先順位付けおよび/または見積もりのために Issue を評価しているときに発生します。あなたがこのトリアージを行う人である場合、以下のいずれかの行動方針を取ることができます。

1. それが明確に自分のグループのカテゴリに該当すると判断した場合は、自分の内部トリアージ手順に従う。
2. それが明確に別のグループのプロダクトカテゴリに該当すると考える場合は、Issue のコメントスレッドで非同期にそのグループの EM または PM に ping する。なぜそれが彼らの管轄に該当すると考えるのかの理由を説明し、オーナーシップを引き受けるよう依頼する。依頼し、彼らがあなたのコメントを見て、その Issue を引き受けるのにより適していると同意したときに、彼らにラベルを更新してもらう ようにしてください。
3. Issue が共有責任カテゴリに該当すると考える場合は、まず、自分のチームがその Issue にコントリビュートし、完了まで見届けるオーナーになることを慎重に検討してください。ただし、自分のチームがスキルを持っていない、または時宜を得て Issue にコントリビュートするのに必要な知識とスキルを習得できないと考える場合は、より適している（または自分のグループが協力して機能を一緒に提供できる）他のグループを特定してみてください。その時点で、彼らと会話を始め、明確なオーナーが決まるまで Issue のさらなるトリアージを調整してください。あるいは、このトリアージプロセスを通じて、Issue が追求する価値がない（例えば、価値対労力を考慮して）と集団的に判断する場合もあります。この場合は、決定の明確な根拠を提供しながら、Issue を必ずクローズしてください。

トリアージを進める中で、あなたと EM/PM の仲間が Issue の価値、深刻度、優先度、グループの管轄について合意できない場合に、いつ Issue をより上位のレベル（すなわちシニアマネジメント、ディレクター以上）にエスカレーションすべきかを判断するために、あなたの判断を働かせてください。今のところ、エスカレーションの方法は柔軟であり、状況に合った適切なコミュニケーションチャンネルとモダリティを選べます。

DRI として、影響を受ける領域の継続的なサポートを確保するための追加のステップを取ることを検討すべきです。これには、当該コンポーネントの継続的な責任と技術戦略を引き受けられる新しいプラットフォームグループの作成の提案を提出することが含まれる場合があります。これはもちろん、自分のグループに割り当てられた Issue に即座に対処する必要性を排除するものではありません。

トリアージプロセスの結果として、あるグループが恒久的にオーナーシップを引き受ける資格があり、その意思があると特定された場合、プロダクトとエンジニアリングのリーダーは、Development ハンドブックの shared services components セクションに、オーナーシップモデルのタイプとチームを正式に文書化すべきです。適切と判断される場合、複数のグループが同じコンポーネントのオーナーシップを恒久的に共有することもできます。

このプロセス全体を通じて、グループのリーダーとして、あなたは Issue が解決されるか、他の誰かが引き継ぐことに同意するまで、初期の Directly Responsible Individual (DRI) とみなされることを覚えておくことが重要です。他のグループとのさらなるトリアージの会話なしに単に自分のグループラベルを削除することは、このプロセスにおいて受け入れられる、または役立つ行動ではありません。これは私たちの Results: global optimization のバリューに沿っています。

古くなった Issue

過去 3 か月間に更新されていない Issue には、「Awaiting Feedback」ラベルを追加すべきです。14 日後、その Issue について誰からも応答がない場合、Issue はクローズすべきです。これは、古くなった Issue に関する Rails Core ポリシーをわずかに修正したバージョンです。

将来のいずれかの時点で応答があれば、Issue の再オープンを検討できます。Issue が GitLab の最近のバージョンにまだ存在することを確認できない場合、私たちは Issue トラッカーにノイズを加えているだけです。

重複

重複を見つけるには:

• その Issue が対象とするプロジェクトの Issue トラッカーを開く。
• Issue から関連するキーワードを入力する。
• 結果リストの最初のページをざっと見る。
• オープンとクローズの両方の Issue を確認する。

より良いタイトル、説明、またはより多くのコメントとポジティブなリアクションを持つ Issue を正規バージョンとして使用してください。決められない場合は、より古い Issue を残してください。

サポート Issue メッセージ

Issue が実際にはヘルプを求めるサポートリクエストである場合は、Issue triage - support question コメントテンプレートを使用できます。

重複 Issue メッセージ

重複を見つけた場合は、このメッセージを投稿できます。

Hey {{author}}! Thanks for submitting this issue. It looks like a duplicate of {{issue}}. I'm marking your issue as a duplicate and close it.
Please add your thoughts and feedback on {{issue}}. Don't forget to upvote feature proposals.

/duplicate {{issue}}

重複 Issue が割り当てられるかもしれないマイルストーンの目標について、将来を見越した発言をしないでください。

クローズに傾く

私たちはすべての人を満足させることはできません。できる限りユーザーを満足させることと、プロジェクトをメンテナンス可能に保つことのバランスを取る必要があります。

• Issue が再現手順やバージョン情報のないバグレポートである場合は、Issue をクローズし、報告者により多くの情報を提供するよう求めてください。
• 機能/変更を確実に追加しない場合は、そう伝えて Issue をクローズしてください。

Issue が来たらラベルを付ける

Issue が来たら、トリアージしてラベルを付けるべきです。ラベルのない Issue は見つけにくく、しばしば失われてしまいます。

深刻度ラベルには注意してください。深刻度を過小評価すると、解決が本来よりも長く待てるかのように示唆して、問題を悪化させる可能性があります。利用可能な深刻度ラベルをレビューしてください。バグに対する正しいラベルが確信できない場合は、深刻度を過大評価してもかまいません。ただし、ドメインエキスパートから確認を得てください。

自分が開いた Issue のオーナーシップを持つ

「Author: あなたのユーザー名」で並べ替え、修正済みであることがわかっている、または他の理由で関係なくなった Issue をクローズしてください。まだラベルが付いていない場合はラベルを付けてください。

プロダクトフィードバック Issue

一部の Issue はタイプラベルに該当しないかもしれませんが、GitLab の機能がどのように使われているかについての有用なフィードバックを含んでいます。 これらの Issue は、プロダクトマネージャーにメンションし、グループ、カテゴリ、ステージのラベルに加えて ~"Product Feedback" とラベル付けすべきです。 https://gitlab.com/gitlab-org/gitlab/-/issues/324770 はプロダクトフィードバック Issue の例です。

質問/サポート Issue

それが質問であるか、何らかの理由で開発チームが対処できない曖昧なものである場合は、クローズして、私たちが持っている関連するサポートリソース（例: https://about.gitlab.com/get-help/、Discourse フォーラム、または Support へのメール）を案内してください。

新しいラベル

さまざまな Issue の間に共通のパターン（例: まだ専用のラベルがない新機能）に気づいた場合は、Slack または新しい Issue で新しいラベルの追加を提案してください。

Issue の再現

可能であれば、報告者に GitLab.com 上の公開プロジェクトで Issue を再現するよう求めてください。issue-reproduce グループで自分で試すこともできます。アクセスについては、そのグループの任意のオーナーに尋ねることができます。

ノート

これらのポリシーに関する元の Issue は #17693 です。時間が経つにつれて、GitLab 自体の内部から状況を改善するよう取り組んでいきます。

これらのポリシーを作成する上で、以下のプロジェクト、リソース、ブログ投稿が非常に役立ちました。

• CodeTriage
• How to be an open source gardener
• Managing the Deluge of Atom Issues
• Handling Large OSS Projects Defensively
• My condolences, you’re now the maintainer of a popular open source project
• The Art of Closing

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