統合の修正を送信する方法
Toolkit Community へのご協力を歓迎いたします。発見したバグに対する修正プログラムを作成した場合や、Toolkit に追加するべきと思われる機能を実装した場合は、下記のガイドラインに沿って適切なチャネルまでお送りください。
お問い合わせ
開発や修正が必要なものがある場合は、まずお話をお聞かせください。適切な方向に進むための、あるいは不要な作業を回避するための情報を提供できるかもしれません。最も重要なことは、ユーザの皆様が何を作成したいのか、Toolkit をどのように使用するのか、その成果に当社がどのように貢献できるのかについて、実際に話をさせていただくことです。
Github からリポジトリをフォークする
Toolkit エンジン、アプリ、フレーム ワークコードのほとんどは Github で公開されています。変更しているリポジトリを Github からローカル環境にフォークしてみてください。
変更を加える
開発作業はブランチでローカルに行い、専用の環境で当社に提出できる状態になるまでテストしてください。既存のコードベースにスタイルを合わせるようにしてください。変更の内容は目的の範囲内に限定してください。たとえば、コード内の 3 行のバグを修正する場合に、ファイル全体に渡ってスペースの問題を修正することは避けてください。Toolkit に潜んでいる別の問題を引き起こしてしまう可能性があります。
コメント
作業の内容と、その理由についての詳細なコメントを忘れずに追加してください。他のユーザが後でこのリポジトリをフォークするときに、コードの内容と作成された理由について理解する必要が生じる場合があることにご注意ください。簡潔な内容とし、コメントは長すぎないようにしてください。:)
テスト
実際の環境や変数はユーザによってさまざまであり、スタジオで使用しているものとは一致しない場合があります。Toolkit は、そのような条件がユーザに及ぼす影響を最小限に抑えようとしますが、ユーザの環境によって状況が異なるのは当然のことです。次に例を示します。
- コードは OS X、Windows、Linux で同じように動作しますか?
- すべてのサポートされているバージョンのソフトウェアで動作しますか?
- ターミナル、SG Desktop、ShotGrid、または独自のカスタム アプリのどこから起動していても同じように動作しますか?
プル リクエストを作成する
準備ができたら、変更を Github にプッシュしてプル リクエストを作成します。プル リクエストは詳細に記述し、コードの実行内容と変更が必要な理由を含める必要があります。プル リクエストを書くときには、このコード領域に関する知識をほとんど持たないユーザのことを考慮してください。一般のユーザがプル リクエストを見て、丁寧な記述を読み、理解できる内容であることに満足するでしょう。
次に行うこと
当社は、プル リクエストを時間のあるときに短時間で見直します。通常は、コードまたはユースケースについてコメントしたり、質問したりすることがあります。リクエストをユーザに戻して、変更を依頼する場合があります。気を悪くなさらないでください。当社はユーザに対する貢献を大切にしていますが、技術的な内容については深い知識を持っています。日々コードに向き合っていますが、誰もが完璧なコードを一度で作成できるとは考えていません。
レビュー後、承認されたプル リクエストは QA のキューに入れられ、リポジトリに統合されて、特定のタイミングでリリースされます。タイムラインはさまざまな要因によって異なります。しばらくお待ちいただく場合もあります。
プル リクエストが却下される場合もあります。ここでも、気を悪くなさらないでください。ご協力に感謝します。却下されるのにはいくつかの要因があります。しかし、上記のガイドラインに従えば、おそらくそのような事態は回避できるでしょう。