コントリビューターガイドライン

Cordova の改善にご協力いただきありがとうございます！このページでは、Cordova への貢献に関する一般的なガイドラインを示しています。このページに記載されていない情報が必要な場合は、お気軽に 開発者メーリングリスト にご連絡いただくか、Cordova Slack でご質問ください。

前提条件

Apache Cordova に貢献する前に、メーリングリスト に参加し、簡単な自己紹介を送信することをお勧めします。

課題の取り組み

すべての Apache Cordova コンポーネントに関する課題は、GitHub にあります。課題を報告する際には、これらのガイドラインに従ってください。

課題の担当

取り組みたい課題が見つかった場合は、担当を依頼できます。担当したい旨とコミットメントをコメントに残すと、コミッターが担当を割り当てます。課題に取り組んでいないことが明らかな場合は、ご自身で作業を進めていただいて構いません（ただし、担当者に事前にコメントを残してください）。

コードの提出

コードは、github.com/apache/<repo name>にある Apache Github ミラーのいずれかにプルリクエストを送信することで提出できます。

プルリクエストの作成

GitHub でプルリクエストを作成するワークフローは、一般的に次の手順に従います。

1. まだ作成されていない場合は、課題を開く（任意）
2. 適切な Cordova リポジトリのローカルフォークを作成する
3. ローカルフォークで、作業中の課題専用のブランチを作成します。
4. このブランチにコミットをプッシュします。
5. これらのコミットを1つのコミットに圧縮する（コミットメッセージに関する以下のセクションを参照）
6. Cordova リポジトリにプルリクエストを作成する
7. コードレビューを依頼する

GitHub に作成したプルリクエストのタイトルには、課題の ID を含めてください。Git の詳細については、Git ドキュメントを参照してください。

コードレビュー

コードの提出方法に関わらず、常にレビュー担当者を指名して、コードの確認とマージを行うようにしてください。GitHub は、追加できる可能性のあるレビュー担当者を提案してくれます。または、プルリクエストへのリンクを添えて 開発者メーリングリスト にメールを送信することもできます。

コードのテスト

プルリクエストを送信する前に、変更内容のテストと問題の修正を行う責任があります。テストには、追加/変更された機能の検証と、回帰がないことを確認するためのテストスイートの実行が含まれます。

「テストスイートを実行する」とは、以下のことを意味します。

• cordova-mobilespec のすべての自動テスト
• 変更によって影響を受ける可能性のある cordova-mobilespec の手動テスト
• JS リンティングのための npm test
• プラットフォーム固有の単体テスト
  • cordova-android: npm run test-build
  • cordova-ios: npm test
  • cordova-js: jake test
  • cordova-plugman: npm test

行ったテスト内容を課題にコメントとして追加してください。これにより、コミッターはマージする前にどのようなテストが行われたかを理解できます。

テストの追加

可能であれば、変更内容を検証し、将来の回帰をキャッチするテストを含めてください。ほとんどのリポジトリには、そのコンポーネントのテストを含む tests/ ディレクトリがあります。

Git コミットメッセージ

貢献する際には、コミットメッセージの先頭に課題 ID（存在する場合）と関連するプラットフォーム（該当する場合）を記述し、その後にコミットの説明を記述してください。GitHub の課題 ID は GH- をプレフィックスとして付ける必要があります。これにより、GitHub は課題と PR を自動的にリンクできます。

GH-2345 android: Improved exec bridge by using strings instead of JSON
GH-3456 all: Fixed plugin loading paths that start with /

他の人が理解できるだけの詳細さで Git コミットを説明することを強くお勧めします。そのため、コミットメッセージは複数行で構成される場合があります。ただし、コミットメッセージの最初の行は 50 文字以内にすることを強くお勧めします。これは、Git の上位にあるツール（リポジトリを参照できる httpd アプリなど）の一部が、最初の行を 50 文字以下の最上位のサマリーと想定しているためです。したがって、これらの仮定を使用してコミットメッセージの強調表示と切り捨てが行われ、これらの仮定が保持されていない場合、奇妙に見えるでしょう。サマリーとそれ以降の説明の間には、空行も入れる必要があります。たとえば、次のコミットメッセージは適切です。

GH-1234 Fixed the whizbang widget

- added more sanity checking in the build script.
- fixed the API to return the correct value in the scenario where there
  aren't any whizbangs present.
- corrected the documentation.

箇条書きの代わりに、長文を段落形式で記述することもできます。各行は 72 文字で折り返し、段落間には空行を入れます。