Node-REDへの貢献

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

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

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

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

アイテムに対して作業を担当するコントリビュータがいる場合、 次のステップは変更の質に依ります。

既存のノードに新しいオプションを追加するなどのように、 影響が限定的で明確に定義されている機能である場合には、 適切なリポジトリにfeatureラベルがつけられたissueが挙げられる必要があります。 issueには機能の詳細と必要なキーデザインポイントが書かれていなければなりません。 このissueは提案を洗練することにも利用されます。 issueは現在誰が取り組んでいるかを明確に特定できるようにする必要があります。 これは作業の偶発的な重複を避け、作業への集中を保証するためです。

実装するために複数のプルリクエストを必要とする、またはエンドユーザに与える影響が大きいような、 より広いスコープの機能である場合、 node-red/designsリポジトリにデザインノードを作成する必要があります。

デザインが承認され、in-progress状態に移行すると、 適切なリポジトリにfeatureラベルがつけられたissueを挙げる必要があります。 デザインが機能についての提供段階を決めている場合、必要に応じて各段階ごとにissueを挙げるべきです。 issueはデザインノートを参照する必要があります。 特定のリリースを予定している場合は、それぞれのissueにマイルストーンを設定する必要があります。

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

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

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

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

マージされたら、対応する機能の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として将来リリースされる予定のいくつかの修正が含まれています。
• dev - このブランチは次回のマイルストーンリリースに向けた開発作業を含んでいます。 ここでは新しい機能が開発されています。
• より大きな機能はそれぞれ独自のブランチで開発され、 機能が幅広い利用に対して 十分に安定したときに開発ブランチにマージされます。

ツール

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

• フォーラム

  ここはプロジェクトについての主なディスカッションの場です。誰でもフォーラムに参加することができます。

• Slack

  活発で、リアルタイムで、対話的なSlackはフォーラムよりも生産的です。 誰でもSlackチームに参加することができます。 #devチャンネルはプロジェクト開発についてのディスカッションに利用されます。

• Trello - Whiteboard

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

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

• Trello - Documentation

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

• GitHub - code

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

• GitHub - issues

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

• GitHub - pull requests

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

• GitHub - wiki

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

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

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