ちょっとPrism for Xamarin.FormsでPull Request送りたい案件があったので、PrismにContributeするためのルールを翻訳してみました。
なお本エントリーは、解説ではなく私がやりたいので、私の解釈が間違っていないかマサカリを投げてもらうためのエントリーです！
特に赤字のところが自信ありません。。。
誰か、助けて！
2016.10.16 19:00追記
投稿した直後にご支援いただき釈然としていなかった辺りは修正いただけました！
@takuya_takeuchiさん、@espresso3389さんありがとうございました。
Prism/CONTRIBUTING.md at master · PrismLibrary/Prism · GitHub
Contributing to Prism
Welcome! We would love to have you contribute bug fixes or new functionality to Prism.
ようこそ！私たちはPrismへのバグフィクスまたは新機能追加に対する貢献を歓迎します。
The best starting point is to enter an issue here.
最も良い出発点は、ここのissueに記入することです。
We can then have a brief discussion on what you want to do and where it fits with our milestones and goals for the library.
私たちはその後、あなたが何を求めているのか、それは私たちのマイルストーンやゴールと適合するかどうか議論します。
As long as it sounds like something we would want to add to Prism, we will give you a thumbs up and ask for a pull request.
もし、私たちのマイルストーンやゴールと適合するようであれば、私たちはプルリクエストをお願いすることでしょう。
When you submit a pull request, there are a few things we would like you to comply with:
プルリクエストを送る場合、以下を遵守してください。
- New functionality must have accompanying unit tests with "good" code coverage if it is logic code that can be unit tested (i.e. not view stuff touching UI or platform APIs)
新しい機能が、ロジックコードのような（つまり、タッチUIを含むViewやプラットフォームAPIではない）テスト可能なコードである場合、十分なカバレッジのユニットテストコードと共に申請してください。 Changes to existing functionality needs to be checked that it does not break any existing unit tests.
既存機能の変更する場合、既存のUnit Testが破壊されないことを確認してください。
If it does, then fixes to the unit test may be appropriate, but only if those changes maintain the original intent of the test.
既存のUnit Testが破壊される場合、Unit Testへの修正が適切かもしれませんが、既存のテストの意図が尊重される場合にのみ、そうすべきです。Some basic coding standard guidelines to start with:
幾つかの簡単で標準的なコーディングガイドラインを守ってください- no leading "this."
thisを使用しない - single type per file
1ファイル1クラス - interface-based design to preserve testability and extensibility
テスト容易性と拡張性のためにインターフェースベース設計を適用すること - due consideration for inheritance (i.e. consider carefully whether something should be protected or virtual)
継承のために十分に配慮する（つまり、protectedにするかvirtualにするか、十分に検討すること） - member variables have leading underscore and are _camelCased
メンバ変数はアンダースコアから始まるCamelケースとする - local variables are camelCased with no prefix
ローカル変数はプレフィックスのないCamelケースとする - types, properties, methods, events are PascalCased
Type、プロパティ、メソッド、イベントはPascalケースとする - use new C# features (e.g nameof) where possible, but keep the code readable (e.g. don't var everything)
可能な場合、新しいC#の機能（例えばnameof）を利用しますが、可読性は維持すること（何でもかんでもvarにしないなど）
- no leading "this."
Contribution License Agreement
You must sign a .NET Foundation Contribution License Agreement (CLA) before your PR will be merged.
あなたのRPがマージされる前に、.NET Foundation Contribution License Agreement (CLA)に必ず合意すること。
This a one-time requirement for projects in the .NET Foundation.
これは.NET Foundationのプロジェクトとして必要な要件です。
You can read more about Contribution License Agreements (CLA) on wikipedia.
WikipediaにてContribution License Agreements (CLA)の詳細を確認することが可能です。
However, you don't have to do this up-front.
しかし、前もってライセンスを読まなくても構いません。
You can simply clone, fork, and submit your pull-request as usual.
シンプルにforkしてpull-requestを送ることができます。
When your pull-request is created, it is classified by a CLA bot.
あなたがpull-requestを送ると、CLA botが自動的に分類します。
If the change is trivial, i.e. you just fixed a typo, then the PR is labelled with cla-not-required.
些細な習性であった場合（例えばタイプミスの修正のような）、PRに cla-not-requiredをラベリングします。
Otherwise it's classified as cla-required.
そうではなかった場合、cla-requiredとして分類されます。
In that case, the system will also tell you how you can sign the CLA.
この場合、システムはあなたにCLAへのサイン方法を通知します。
Once you signed a CLA, the current pull-request will be labeled cla-signed and all future pull-requests as cla-already-signed.
一度CLAに署名すると、現在のpull-requestには「cla-signed」ラベルが付与され、以後のpull-requestも対しては「cla-already-signed」ラベルが付与されます。
