バグ分類のガイドライン

このページでは、Godotの`GitHub<https://github.com/godotengine/godot>`_repositoryで問題やプルリクエストを処理する際の、バグ分類チーム、別名バグチームの典型的なワークフローについて説明します。これはバグチームと一緒に進化することになっているので、次のガイドラインの修正を提案することをためらわないでください。

問題管理

GitHubは課題を管理するためのさまざまな機能を提案します:

  • 定義済みリストから1つまたは複数のラベルを設定する
  • 定義済みの一覧からマイルストーンを1つ設定する
  • プロジェクト・ダッシュボードで問題を追跡する
  • Godotエンジン組織メンバーの間で1人の貢献者を「担当者」として定義します

GitHubのGodotエンジン組織には現在、限られた数の貢献者しかいないため当面は譲受人を広範囲に使用しません。すべての寄稿者は問題があればそれをissueチケットに記載したり、他の開発者と解決するための最善の方法を話し合った後で関連しているなら、どのような問題でも解決することを歓迎します。

当面はプロジェクト・ダッシュボード機能も使用しません。

可能な限り、ラベル(および関連する場合はマイルストーン)をissueとpull requestの両方に割り当てます。

ラベル

現在、Godotリポジトリでは以下のラベルが定義されています:

カテゴリ:

  • Archived: 他の問題の重複、または無効です。 このような問題も解決されるでしょう。
  • Bug:正しく動作していないものを示します。
  • Confirmed:バグ報告者以外の少なくとも1人の貢献者によって確認されています(通常はバグ報告用)。 このラベルの目的は、作業対象を選択するときに、どの問題がまだ再現可能であるかを開発者に知らせることです。 したがって、問題を再現できるプラットフォームとGodotのバージョンまたはコミットに関するコメントを追加することをお勧めします。 開発者が1年後に問題を見ると、Confirmedラベルはもう関係ないかもしれません。
  • Discussion:問題は合意に達しておらず、トピックに対処するために何をすべきかを正確に定義するために、さらなる議論が必要です。
  • Documentation: ドキュメントに関連する問題。主に APIドキュメントの機能強化を要求します。ReadTheDocs ドキュメントに関連する問題は、 godot-docsリポジトリに提出する必要があります。
  • Enhancement: 既存の機能に対して提案された拡張機能について説明します。
  • Feature proposal:新機能の実装希望を記載しています。
  • Junior job:問題は修正しやすいものであると仮定され、コードベースに精通する必要があるジュニア貢献者に最適です。
  • Needs rebase: 問題をマージするにはgitリベースが必要です。
  • Needs testing: 問題/プルリクエストを完全にテストできなかったため、さらにテストを行う必要があります。これは、異なるハードウェア/ソフトウェア構成でテストする必要があること、または再現する手順が明確でないことを意味します。
  • PR welcome / hero wanted!:これらのラベルに関する問題への貢献を特に歓迎します。ただし、これらのラベルがないと問題に対処できないわけではありません。
  • Tracker:他の問題を追跡するために使用される問題(プラグインシステムに関連するすべての問題のような)。
  • Usability:ユーザーの使いやすさに直接影響を与える問題。

カテゴリは、問題の一般的な優先順位付けに使用されます。例えば、ユーザビリティを向上させるための問題であれば、EnhancementUsability というラベルを同時に付けることができます。あるいは、合意に達していない機能要求であったり、作業するのに十分に正確でないものであれば、Feature proposalDiscussionです。

トピック:

  • Assetlib:アセットライブラリの問題に関連します。
  • Audio:オーディオ機能(低レベルと高レベル)に関連しています。
  • Buildsystem:SConsビルドシステムまたはコンパイラの特殊性にリンクされたビルドの問題に関連します。
  • Core:コアエンジンに関連するもの。それはかなり大きな話題なので、後でさらに分割されるかもしれません。
  • Drivers: エンジンで使用されるドライバの問題に関連します。
  • Editor:エディタの問題(主にUI)に関連します。
  • GDNative:GDNativeモジュールに関連します。
  • GDScript:GDScript に関連します。
  • Mono: C#/Mono バインディングに関連します。
  • Network:ネットワークに関連します。
  • Physics:物理エンジン(2D/3D)に関連します。
  • Plugin:プラグインの書き込み中に発生した問題に関連しています。
  • Porting:いくつかの特定のプラットフォームに関連しています。
  • Rendering:2Dおよび3Dレンダリングエンジンに関連します。
  • VisualScript: ビジュアルスクリプト言語の問題に関連します。

通常、問題は1つのトピックにのみ対応しますが、2つの案に当てはまる問題を見つけることは考えられません。 一般的な考え方は、すべてのトピックの背後に専門の貢献者チームがあるため、チームのトピックでラベル付けされた問題に集中できるということです。

プラットフォーム:

AndroidHTML5iOSLinuxmacOSWindowsUWP

デフォルトでは、特定の問題がすべてのプラットフォームに適用されると想定されています。プラットフォームラベルのいずれかが使用された場合、それは排他的であり、以前の前提はもはや存在しません(AndroidとLinuxのみのバグの場合は、この2つのプラットフォームを選択してください。)。

マイルス トーン

マイルストーン は、既存のロードマップがあるGodotの将来のバージョンの計画に対応します。上記のロードマップに適合する問題は、対応するマイルストーンの下に提出されるべきです。;現在のロードマップに対応していない場合は、マイルストーンを設定しないでください。大ざっぱに言って、ある問題があるマイルストーンに対応するのは、そのマイルストーンの新しい機能や、将来の安定版リリースでは受け入れられない重大なバグ、あるいはJuanが今すぐ取り組みたいと思っていることに関係している場合です :)

貢献者は、割り当てられたマイルストーンに関係なく、問題を自由に選択できます。 緊急とみなされなかったため、マイルストーンのないバグの修正が提案された場合、それでも大歓迎です。