Unity プロジェクト用のワールド ロック ツールに貢献する

  • [アーティクル]

現時点でワールド ロック ツールプロジェクトに貢献する最も有益な方法は、問題のファイリングです。 Unity プロジェクトのワールド ロック ツールをプロジェクトのニーズにうまく合わせるためのあらゆるフィードバックは非常に貴重です。

投稿したフィードバックは貴重ですが、ここでは、より実用的なものにするためのヒントをいくつか紹介します。

ラベルを適切に使用する

最初に問題を提出するときと、共同作成者として問題をフォロー アップするときの両方で、ラベルを適切に使用することは、他の共同作成者との調整に非常に役立ちます。

バグとは何か、機能要求とは何か、そして今後に向けたより広範な提案とは何かを正確に区別するようにしてください。 すべて価値あるものですが、そのように識別すると、より価値が増します。

同様に、問題が現在の形式では対応できないように思われる場合は、適切なラベル (たとえば、"不明確") を付けることで、対応可能な場所を発見することの改善をサポートできます。 もちろん、問題自体への具体的なコメントは非常に価値があります。 しかし、適切なラベルを付けると、ラベル無しでは見過ごす可能性のあるコメントを他のユーザーが見る可能性があります。

バグの報告

問題は、GitHub の懸案事項ポータルから送信できます。 時間をかけて問題を報告したり、他のユーザーにもメリットがあることを提案したりすることは、いつでも歓迎です。

バグ レポートにはそれぞれ固有のコンテキストがありますが、一般的に、次のような項目が多く含まれていると、問題をより迅速に解決できます。

デバイスからのログ ファイル

デバイスからのログ ファイルは、特に、以下に示す画面キャプチャと組み合わると、問題の調査に計り知れないほど役立つ可能性があります。 これらは、デバイスに接続しているときに、 Windows デバイス ポータルを使用してシステム >ファイル エクスプローラー > のユーザー フォルダー \ LocalAppData \ WorldLockingTools の下で取得できます

Unity アプリのログ ファイル

UnityPlayer.log は、 TempState サブフォルダーにあります。 これはプレーン テキスト ファイルです。

ワールド ロック ツール診断の記録

診断ファイルは、 LocalState サブフォルダーにあります。 ファイル名は、次のパターンに従って自動的に生成されます：

FrozenWorld-<device name>-<capture date and time>.hkfw

これは、調査には専用のソフトウェアが必要なバイナリ ファイルです。

診断記録をキャプチャするには、シーンでワールド ロックツール マネージャー コンポーネントの診断記録を有効にする必要があることに注意してください。 詳細については、 診断 のドキュメントを参照してください。

Repro steps (再現手順)

問題発生のたやすさを指定します。 理想的には、特定の一連の手順に従って 100 % の確率で発生するバグです。 ただし、一度しか発生しなかったバグでも、問題に至る手順をより詳細に関連付けられれば、より良いことでしょう。

再現手順は、次の一般的な形式に従う必要があります：

  1. 通常の安定した状態から始めます...
  2. それから、私はこれを行いました（または、おかしなことに気付きました）...
  3. それから、システムはこの誤った動作を示し始めました...

画面のキャプチャ

画面キャプチャは、問題が発生したコンテキスト全体を特定するのに役立ちます。 具体的には、ワールド ロック ツールの診断を画面に表示すると、エクスペリエンスをログの情報に関連付けるのに役立ちます。 画面キャプチャは、スナップショット イメージまたはビデオ キャプチャのいずれかになります。

デバイス情報

  • What type of device? (デバイスの種類)
  • どの OS バージョンを実行していますか?

ビルド環境

  • Unity のバージョン
  • Visual Studio のバージョン

機能を提案する

ワールド ロック ツールが ほぼ 必要な処理を実行していることがわかった場合、他のユーザーが同じ制限を受けている可能性があります。 新しい機能を提供する場合と同じように、ドキュメントと例の間のギャップを修正することに関心があります。

新しい機能を提案する際には、何を実行しようとしているのかを明確にすることが最も重要です。 実装方法についてのアイデアも役に立ちますが、付加価値を明確にする提案は、牽引力を得る可能性が高くなります。 その機能が解決する問題を明確にします。可能であれば、実際のシナリオで達成できることにしてください。

"拡張機能" ラベルを、送信された問題の提案に必ず添付してください。

コードの投稿

これはオープンソース プロジェクトであるため、もちろん、いつでも開発用のフォークを作成できます。 誰かが作業をシェア バックするくらい十分な余裕があるならば、メイン リポジトリに折り返されるかどうかにかかわらず、大幅に評価されます。

この最初のロールアウト期間中は、メイン リポジトリへのプル要求を確認して受け入れるためのリソースが限られています。 メイン リポジトリにマージ バックされることを前提として、フォークに多くの時間を費やすことは避けることをお勧めします。

リスクを低減するための1つの方法は、実装に多くの時間を費やす前に、意図したもの ("拡張"とラベル付けされている) を提案する問題を提出することです。 これは、同じ問題領域を見ている可能性のある他の共同作成者にも配慮しています。

関連項目

コーディング規則のリリース プロセス