f:id:yoshiki_utakata:20181004212834j:plain

はじめに

https://github.com/playframework/playframework にプルリクエストを出そうとすると、「How to write the perfect pull request」と「Contributor guidelines」に目を通すように言われます。前者については OSSでプルリクを出すために、GitHubが出している「どうやって完璧なプルリクエストを書くか」を読む - WebエンジニアのLoL日記で読みましたので、今回は playframeworkのContributor guidelinesについて読んでいきます。

Play contributor guidelines

issue立てるとき

ドキュメントの簡単な修正の場合はissueを立てずにすぐにプルリクエストを出してください。これが一番早いと思います。
バグかどうか100%の確信がない場合、Play Framework forum でたずねてください。新機能の議論についてはメーリングリストがよいです。issueはバグのためのもので質問のためのものではありません。
バグであると確信して初めてissueを立ててください。可能な限り詳細に書いてください。実際に問題が起こるサンプルコードと結果、スタックトレースなどを含めてください。Play, Java, OSの種類やバージョンなどの情報も含めてください。

コントリビュートする

はじめに

Lightbend CLA に登録してください（詳細は別ブログで書きます）。オンラインで登録できます。
あなたの変更が以下のガイドラインに適しているかを確認してください。
- コーディング規約
  - DRYの原則 *1
  - ボーイスカウトのルール *2
- 新機能かどうかや、バグ修正かどうかにかかわらず、全体テストを通してください。テストが無いコードを修正した場合もです。
- 以下の実装は可能な限り避けてください
  - グローバルな状態管理・変数
  - publicかつmutableな状態管理や変数
  - implicit conversions（暗黙の型変換） *3
  - ThreadLocal
  - Locks
  - Casting
  - 新しく強い依存性を導入すること
- Play API の設計ルール
- PlayはJavaとScalaのフレームワークです。ScalaとJavaの両方で同じ変更をするようにしてください
- JavaのAPIは framework/play/src/main/java 以下にあり、パッケージ名は play.myapipackage.xxxx
- ScalaのAPIは framework/play/src/main/scala 以下にあり、パッケージ名は play.api.myapipackage
- 新機能がフレームワークのコア機能であるべきか、1モジュールとして実装されているべきか考えてください
- コードがコーディング規約にのっとっていて、テストが通る必要があります
- 新しいファイル
  - コピーライトを以下のように書く必要があります。 Copyright (C) 2009-2016 Lightbend Inc. <http://www.lightbend.com>
  - @author タグは使わないでください
コミットはSquashしてください。詳細は https://www.playframework.com/documentation/ja/2.4.x/WorkingWithGit を読んでください。
プルリクエストを出してください