BlueMonkey の開発に参加していただきありがとうございます。 作業される方は、以下の手順に従ってください。
※この文章は以下を参考にさせていただいています。
- issue を立て変更内容について協議する
- 作業着手の意思表示をする
- コーディングする
- コーディング後の作業を行う
各手順の詳細は以下の通りです。
本プロジェクトについて何らかの意見・提案がある場合、まずは issue を立ててください。
私たちはその提案が、私たちのマイルストーンやゴールと適合するかどうか協議します。
もし、私たちのマイルストーンやゴールと適合するようであれば、私たちはプルリクエストをお願いすることでしょう。
issue に対して合意がなされたら、まずは Work In Progress(WIP) の Pull request を送ることで作業着手の意思表示をしてください。
これは貴重な開発リソースが重複して無駄になってしまうことは避けるためです。
詳細な手順は以下の通りです。
- このリポジトリを自分のリポジトリとして fork する
- なにも編集せず空コミットする →
git commit --allow-empty -m "○○画面の実装を始めます" - 自分のリポジトリに push する
- このリポジトリに Pull request を送る。PRのタイトルに [WIP] 付けること（例：[WIP]○○画面を実装します）
2.は意思表明は最速で行っていただくためのであり「1行修正してコミット」でも問題ありません。
可能な限り迅速に、作業着手の意思表示を Pull request してください。
空コミット + Pull request を利用したチーム作業については、以下も参考にしてください。
各々でコーディングしてください。
実装の規模が大きくなる場合は、元の issue で相談するなどして作業を見直してください。
コーディングスタイルやコミットログは、以下のとおりです。
- 新しい機能が、テスト可能なコードである場合（つまり、タッチUIを含むViewやプラットフォームやデバイスに依存するAPIではない場合）、十分なカバレッジのユニットテストコードを共に記述すること
- 既存機能の変更する場合、既存のUnit Testが破壊されないことを確認すること
目的を達成するため Unit Test を修正する必要がある場合もありますが、その場合は既存のテストの意図を十分に尊重し、安易にテストの変更・削除を行わないこと - 新たなライブラリを利用する場合、必ず issue 上で提案し対応についてコミュニティの合意を得たうえで利用すること
その際、Visual Studio環境とXamarin Studio環境何れでもビルドできるよう留意すること （Xamarin Studio環境では関節参照しているライブラリに対して、明示的に参照を追加する必要がある場合があるため） - 以下のコーディングガイドラインを遵守すること
thisを使用しない- 1ファイル1クラス
- *.cs, *.xml, *.xaml のインデントには tab ではなく space4つ を使用してください（ issue #73 に tab の混入を防ぐ設定を案内していますので参考にしてください ）
- テスト容易性と拡張性のためにインターフェースベース設計を適用すること
- 継承のために十分に配慮する（つまり、
protectedにするかvirtualにするか、十分に検討すること） - メンバ変数はアンダースコアから始まるCamelケースとする
- ローカル変数はプレフィックスのないCamelケースとする
- Type、プロパティ、メソッド、イベントはPascalケースとする
- 可能な場合、新しいC#の機能（例えば
nameof）を利用しますが、可読性は維持すること（何でもかんでもvarにしないなど）
- コミットログは以下のガイドラインを遵守すること
- 1行目は英語で概要を記述し、現在形の動詞で開始しすること
- 必要であれば3行目以降に詳細を記述すること
その際、日本語で記述しても良いものとする
例）
1行目: 英語で変更を概要を書く(e.g. Update Xxx, Add Yyy ...)
2行目: 空白行
3行目: 変更についての詳細を書く（日本語で可）
作業完了の意思表示を行ってください。
- 該当の Pull Request のタイトルから [WIP] を除去する
- 該当の Pull Request にコメントする（例：作業完了しました、マージしてください。）