Node-REDへの貢献

いかなる貢献も出発点はコミュニティでのディスカッションです。 そのための望ましい過程はプロジェクトのメーリングリストですが、 Slackチームでのディスカッションも同様に妥当です。これらは次の2つの目的を果たしています。

  • GitHubユーザではない人々を含む幅広い支援者に届けること。
  • 実際には支援依頼または重複している項目を、除外や合理化して処理してから対応できるようにすること。

コミュニティでのディスカッションで結論が出た時点で、リクエストは撤回されるか次の段階に進みます。

コードコントリビュータではない立場のコミュニティメンバからの機能要求については、コミッタによってTrelloホワイトボードに追加されます。 このホワイトボードは作業の優先順位付けの際に技術委員会が汲み上げる可能性のある機能のバックログとして機能しています。

ある項目に取り組んでいるコントリビュータがいる場合、GitHub上のプロジェクトでissueを作成する必要があります。 issueには機能の詳細および必要な設計上のポイントが書かれていなければなりません。また、issueは提案を洗練することにも利用されます。 issueは現在誰が取り組んでいるかを明確に特定できるようにする必要があります。これは作業の偶発的な重複を避け、 作業へ集中できるように保証するためです。

最終的にissueを参照するプルリクエスト(PR)が届きます。

コミッタコミュニティは、適時にPRをレビューする責任があります。 重大な変更があった場合は、PRは週末やその他の休暇期間を考慮して最低48時間リストに掲載されるようにしてください。 これはすべてのコミッタに対して、それぞれのタイムゾーンに関係なくPRをレビューする、もしくは自身の希望を記述する公平な機会を提供します。

未解決の異議がなければ、コミッタはPRを承認します。

異議がある場合、コミッタ間で適切な合意に達しなれければなりません。

issueに関する全てのPRが解消された時点で、issueをクローズすることができます。

プルリクエストの要件

コードの変更をおこなったすべてのプルリクエストは、承認される前にいくつかの基準を満たしていることが求められます。

  1. PRへのすべてのコミッタはJS Foundation CLAに同意しなくてはなりません。同意していないコミッタからの変更をプロジェクトは承認できません。

  2. PRによって初めてプロジェクトがコントリビュートに気がつくべきではありません。前述のとおり、 すべてのコードコントリビュートはコミュニティや事前に作成されているissueで既に議論されているべきです。

    PRがバグ修正を含んでいる場合、議論が必要な変更がないかぎり承認されます。

    重大な変更がある場合、適切なコントリビューションのプロセスに従っていなければ却下される可能性があります。 私達はコントリビューションを思いとどまらせたいわけではなく、適切なレビュー/ディスカッションの過程を省略することを避けたいのです。

  3. ビルドテストはきれいに合格するはずです。テストは各PRに対して自動実行され、報告されます。 このテストは、単体テストおよび機能テストと同様にコードスタイルおよびリントを含んでいます。

  4. 変更には適切なテストカバレッジが含まれている必要があります。コアプロジェクトは90%以上のコードカバレッジの維持を 目標としています。PRがコードカバレッジを低下させる場合、正当な理由がないかぎり却下されます。

このプロジェクトでは、PRをおこなう以前にコード変更のためにどの開発方法論を用いるかという要件は設けていません。 優れたテストカバレッジとドキュメントに対して価値を見出しています。

Gitワークフロー

主なプロジェクトのリポジトリのGitでは以下のワークフローが利用されています。

従来のGitワークフローと同様に、異なる活動ごとに複数のブランチが使用されています。 以下に現在の利用用途について記載しています。

  • master - このブランチにはNode-REDの最新リリース版、およびそれに追加したバグ修正が含まれています。 このブランチはいつでも次のメンテナンスリリースとしてリリースできるでしょう。このドキュメントを書いている時点では、 ブランチには0.16.2と0.16.3として将来リリースされる予定のいくつかの修正が含まれています。
  • 開発ブランチ(例 0.17) - 次回のマイルストーンリリースとして開発作業がおこなわれており、 リリース予定のバージョン番号をとって命名されているブランチです。
  • より大きな機能はそれぞれ独自のブランチで開発され、機能が幅広い利用に対して 十分に安定したときに現行の開発ブランチにマージされます。

ツール

プロジェクトではその活動を支援するため、数多くのツールが利用されています。 以下のリストは、現在利用されているツールとその目的を反映しています。

  • メーリングリスト

    プロジェクトについてのディスカッションをおこなう主なツールです。誰でもメーリングリストに参加することができます。

  • Slack

    活発で、リアルタイムで、対話的なSlackはメーリングリストよりも生産的です。誰でもSlackチームに参加できます。

  • Trello - Whiteboard

    アイデアと機能を高度に追跡できます。既存の機能を拡張したり、より「偉大な」アイデアや機能をバックログに 含めることができるツールです。

    このツールは技術委員会がアイデアや機能に優先順位を決定するために利用します。 誰でもホワイトボードを閲覧することができます。コミッタは書き込み権限を有しています。

  • Trello - Documentation

    特定のコード変更に結び付けられていないドキュメント作成タスクのため、異なるホワイトボードが利用されています。 ユーザ/開発者/コントリビュータそれぞれに適したドキュメントを提供できるようにしています。 誰でもホワイトボードを閲覧することができます。コミッタは書き込み権限を有しています。

  • GitHub - code

    プロジェクトのソースコードのバージョン管理。誰でもリポジトリをクローンまたはフォークできます。 プライベートリポジトリは存在しません。コミッタはリポジトリへのコミットを適用できます。

  • GitHub - issues

    バグ/課題の報告および機能開発の追跡。 誰でもissueを作成することができます。コミッタはissueを「所持」することができます。

  • GitHub - pull requests

    コントリビューションをリポジトリに貢献する方法。誰でもプルリクエストを出すことができます。 そのためのプロセスは別途記載します。

  • GitHub - wiki

    それぞれのリポジトリは関連したwikiがあります。共同でデザイン、アイデアおよびドキュメンテーションを 開発するための作業スペースとして利用されています。

    特に、コアリポジトリのwikiは一連のDesign Notes ページがあります。これはデザインが開発され、フィードバックが求められるスペースです。

    wikiにはアクセス権の制御がありません。誰でも変更をおこなうことができます。しかし、変更は ページに積極的に取り組んでいる人々との共同作業によってのみ実施されるべきです。