課題のワークフロー
取り組むべきイシューの発見
GitLabには75,000以上のイシューがあります。ラベルを使って絞り込み、作業に適したイシューを見つけることができます。新しいコントリビューターは、quick win ラベル](https://gitlab.com/groups/gitlab-org/-/issues/?sort=created_asc&state=opened&label_name%5B%5D=quick%20win&first_page_size=20) で[のイシューを探すことができます。
frontend とbackend のラベルも、イシューリストを絞り込むのに良い選択です。
イシューの明確化/検証
多くのイシューは、最近訪問または検証されていません。イシューを解決しようとする前に、以下のステップを踏んでください：
- そのイシューがまだ適切かどうか、作成者に尋ねてください。
- そのイシューがまだ適切かどうかをコミュニティに尋ねてください。
- どうかを検証してみてください：
- マージリクエストがすでに作成されています（関連するマージリクエストのセクションを参照してください）。イシューがクローズ/更新されていないことがあります。
-
type::bugはまだ存在します (再作成することで)。 -
type::featureはまだ実装されていません(試してみてください)。
イシューに取り組んでいます。
イシューに取り組みたいこと、割り当てを希望することをメモに残してください（作成者および/または@gitlab-org/coaches を明記してください）。
イシューに行き詰まったり、正しく理解できなかったりした場合は、作成者やコミュニティに助けを求めることができます。
イシューを提出する前に、同じようなエントリがないかイシュー・トラッカーで検索してください。誰かが同じバグや機能提案をしているかもしれません。既存のイシューを見つけたら、絵文字のリアクションでサポートを示し、ディスカッションにメモを追加してください。
バグを投稿するには
-
バグ」イシューテンプレートを使用してください。コメント (
<!-- ... -->) のテキストは、どの情報を含めるべきかの参考になるはずです。 - セキュリティの脆弱性が疑われることを報告するには、GitLab.com ウェブサイトの公開プロセスに従ってください。
イシューのトリアージ
イシューのトリアージ方針はハンドブックに記載されています。GitLabチームのイシューのトリアージを手伝うことは大歓迎です。また、四半期に一度、イシューBashイベントも開催しています。
最も重要なことは、有効なイシューが開発者からフィードバックを受けられるようにすることです。そのため、イシューを手伝ってくれる開発者を優先的に紹介します。GitLabチームから関連する経験のある人を選んでください。そのような専門知識を持つ人がいない場合は、影響を受けるファイルのコミット履歴を見て誰かを探してください。
また、ハンドブックに記載されているように、トリアージオートメーションも導入しています。
イシューに適用するラベルについては、ラベルを参照してください。
機能提案
機能提案を作成するには、イシュー・トラッカーに課題を登録してください。
機能提案を追跡しやすくするために、~"type::feature" ラベルを作成しました。当面の間、プロジェクトのメンバーでないユーザーはラベルを追加できません。代わりに、コアチームのメンバーの誰かにラベル~"type::feature" をイシューに追加してもらうか、次のコードスニペットを説明文のすぐ後に改行で追加してください:~"type::feature".
機能提案はできるだけ小さくシンプルにしてください。複雑な提案は小さくシンプルにするために編集されるかもしれません。
機能提案は、イシュー・トラッカーで提供されている「機能提案」テンプレートを使って提出してください。
ユーザーインターフェイス(UI) の変更については、デザインと UI ガイドラインに従い、視覚的な例 (スクリーンショット、ワイヤーフレーム、またはモックアップ) を添付してください。このようなイシューには、プロダクトデザインチームがインプットとガイダンスを提供するため、~UX" のラベルを付けてください。自分でラベルを追加する権限がない場合は、コアチームメンバーの誰かにラベルの追加を依頼する必要があるかもしれません。
自分で何かを作りたい場合は、まずイシューを開いて GitLab に含めることが面白いかどうかを議論することを検討してください。
イシューのウェイト
イシュー・ウェイトを使用すると、1つまたは複数の問題を解決するために必要な作業量を把握することができます。これにより、より正確な作業スケジューリングが可能になります。
イシューのウェイトを設定することをお勧めします。以下のガイドラインに従うことで、不必要なオーバーヘッドを発生させることなく、簡単に管理することができます。
- 可能な限り早い段階でイシューのウェイトを設定してください。
- 設定されたウェイトに同意できない場合、ウェイトについてコンセンサスが得られるまで他の開発者と議論してください。
- イシューの重みは、問題の複雑さを抽象的に測定したものです。イシューの重みを時間に直接関連付けないでください。これはアンカリングと呼ばれ、避けたいものです。
- ウェイトが1（あるいはウェイトなし）のものは本当に小さくてシンプルなものです。重みが9のものは、GitLabの基本的な部分を大きく書き換えるもので、解決するのが難しい問題がたくさん出てくるかもしれません。GitLabのいくつかのテキストを変更することはおそらく1、新しいGit Hookを追加することはおそらく4か5、大きな機能は7-9です。
- とても大きなものであれば、複数のイシューやチャンクに分けるべきでしょう。親イシューの重みを設定して子イシューに重みを設定することはできません。
回帰イシュー
毎月のリリースには、CE issue trackerに対応するイシューがあり、そのリリースで壊れた機能や、パッチリリースに含める必要のある修正を記録しています（例として、8.3 Regressionsを参照してください）。
issueの説明にあるように、意図するワークフローは、リグレッションを説明するissueへの参照を含む1つのノートを投稿し、それが利用可能になると、それを修正するマージリクエストへの参照を含むノートを更新することです。
もしあなたが他のユーザーのノートを更新するのに必要な権限を持っていない貢献者であれば、イシューとマージリクエストの両方を参照する新しいノートを投稿してください。
リグレッションのイシューのノートは、リリースマネージャによって更新されます。
フォローアップ課題における技術的負債
新機能の開発中に技術的負債を発見することはよくあります。実行可能な最小限の変更」の精神から、解決はフォローアップイシューに先送りされることがよくあります。しかし、これを、レビューに通らないような質の悪いコードをマージしたり、独立にスケジュールする価値のない些細なことを見過ごしたりする言い訳にしてはいけません！
スケジューリングのオーバーヘッドやGitLabコードベースの変更率は、些細な技術的負債のイシューのコストがそれを追跡する価値をすぐに上回ってしまうことを意味します。これは一般的に、マージリクエストの中で解決するか、あるいはフォローアップイシューを作成しないことを意味します。
例えば、ファイル間でコピーされているコメントのタイプミスは、同じMRで修正する価値はありますが、フォローアップのイシューを作成する価値はありません。多くの場所で使用されているメソッドの名前を変更して、その意図を少し明確にすることは、修正する価値があるかもしれません。このようなイシューを作成する場合、必ず~P4 ~S4 というラベルが付けられるでしょう。
より深刻な技術的負債は、開発速度に影響を与える可能性があります。もしタイムリーなアドレスがなければ、コードベースは不必要に変更しづらくなり、新しい機能を追加するのが難しくなり、リグレッションが多発します。
このような技術的負債を発見した場合、深刻に扱うべきであり、フォローアップイシューで解決するのが適切かもしれませんが、メンテナーは一般的に、元のMRの作成者、または関連する分野のエンジニアリングマネージャーやプロダクトマネージャーからスケジュールを確約してもらうべきです。これは、イシューに適切な優先度/重要度のラベルを貼るか、明確なマイルストーンと担当者を指定する形になります。
未解決の議論がこの方法で解決される前に、メンテナーは必ず同意しなければなりません。特に、イシューのタイトルはFollow-upで始まってはなりません！特に、issueのタイトルが !