ExpressおよびGitHubのexpressjs組織にある他のプロジェクトは、Node.js Foundationのプロジェクトです。これらのプロジェクトは、Node.js Foundationの一般的なポリシーとガイドライン、および以下の追加ガイドラインに準拠しています。
Express技術委員会は、アクティブなプロジェクトメンバーで構成され、Expressプロジェクトの開発とメンテナンスを指導します。詳細については、Expressコミュニティ - 技術委員会を参照してください。
このドキュメントの目的は、以下のことを実現する貢献プロセスを作成することです。
質問や問題がある場合は、Issueを記録してください。疑問がある場合は、Issueを記録してください。含めるべき追加のポリシーは、回答で提供されます。唯一の例外は、非公開で送信する必要があるセキュリティ開示です。
コミッターは、別のリポジトリに誘導したり、追加の説明を求めたり、Issueが対処される前に適切なメタデータを追加したりすることがあります。
礼儀正しく敬意を払ってください。すべての参加者は、プロジェクトの行動規範に従うことが期待されています。
このリポジトリのリソースに対する変更はすべて、プルリクエストを介して行う必要があります。これは、ドキュメント、コード、バイナリファイルなど、すべての変更に適用されます。長期コミッターやTCメンバーであっても、プルリクエストを使用する必要があります。
レビューなしにプルリクエストをマージすることはできません。
重要でない貢献の場合、プルリクエストは少なくとも36時間保留して、他のタイムゾーンの貢献者がレビューする時間を確保する必要があります。また、週末やその他の休日を考慮して、アクティブなコミッター全員が、希望する場合に議論やレビュープロセスに参加するのに妥当な時間を取れるようにする必要があります。
各貢献のデフォルトは、コミッターからの異議がない場合に承認されることです。レビュー中に、コミッターは、特定の分野に最も精通している特定の貢献者がPRをマージする前に「LGTM」を与えるよう要求することもあります。貢献が実現するための追加の「承認」プロセスはありません。コミッターによって提起されたすべての問題が対処されたら、任意のコミッターがそれをマージできます。
別のコミッターによってプルリクエストで異議が提起された場合、関係するすべてのコミッターは、表明された懸念事項に対処するための議論、提案された変更の妥協、または提案された変更の撤回によって、コンセンサスに達するように努める必要があります。
貢献が物議を醸し、コミッターがそれをどのように実現するか、または実現すべきかについて合意できない場合は、TCにエスカレーションする必要があります。TCメンバーは、解決策を見つけるために、保留中の貢献について定期的に話し合う必要があります。TCに解決のために持ち込まれる問題はごく少数であり、コミッター間の議論と妥協がデフォルトの解決メカニズムであることが期待されます。
誰でもトリアージャーになることができます！トリアージャーになるプロセスについては、トリアージプロセスドキュメントをご覧ください。
expressjs/expressリポジトリでIssueを開き、トリアージロールをリクエストします。行動規範と役割の詳細を読んで同意したことを明記してください。
コピーして貼り付けることができるIssueコンテンツの例を次に示します。
Title: Request triager role for <your GitHub username>
I have read and understood the project's Code of Conduct.
I also have read and understood the process and best practices around Express triaging.
I request for a triager role for the following GitHub organizations:
jshttp
pillarjs
express
Issueを開くと、TCのメンバーがリクエストされた組織のtriageチームにあなたを追加します。その後、Issueはクローズされます。
トリアージをお楽しみください！
重要でない貢献を実現したすべての貢献者は、タイムリーにオンボーディングされ、コミッターとして追加され、リポジトリへの書き込みアクセス権が付与される必要があります。
コミッターは、このポリシーに従い、プルリクエストを送信し続け、適切なレビューを受け、他のコミッターにプルリクエストをマージしてもらうことが期待されています。
TCは、TCにエスカレーションされた問題に対して「コンセンサスシーキング」プロセスを使用します。グループは、TCメンバーの間で未解決の異議がない解決策を見つけようとします。異議のないコンセンサスに達することができない場合は、過半数勝利の投票が行われます。また、TCによって行われる決定の大部分は、コンセンサスシーキングプロセスによるものであり、投票は最後の手段としてのみ使用されることが期待されています。
解決策には、コンセンサスに向けて前進する方法に関する提案とともに、コミッターにIssueを返すことが含まれる場合があります。TCの会議でその会議中に議題のすべての問題が解決されるとは限りません。コミッター間で行われている議論を続けることを好む場合があります。
メンバーはいつでもTCに追加できます。コミッターは別のコミッターをTCに推薦でき、TCは標準のコンセンサスシーキングプロセスを使用して、この新しいメンバーを追加するかどうかを評価します。他のメンバーの大多数のレベルで一貫して参加しないメンバーは、辞任することが期待されています。
expressjs.comウェブサイトの問題は、https://github.com/expressjs/expressjs.comで開いてください。
npm run lintに従ってください。現在のリリースストリームを対象としたバグ修正やマイナーな作業には、masterブランチを使用してください。
Expressの将来のリリースを対象としたものには、対応する名前のブランチ（例：5.0）を使用してください。
npm installを実行して依存関係をインストールし、次にnpm testを実行します。npm run lintを実行してコードがリントされていることを確認します。リストされている問題を修正してください。#123）を含めることによってIssueを参照するようにしてください。通常、記述しているアプリに固有のあいまいなIssueや質問はクローズします。質問のIssueを投稿する前に、ドキュメントやその他の参考文献を再確認してください。
質問のIssueを確認してもらうのに役立つ事項
質問を投稿しても上記の項目の概要を示していない場合、または問題を理解して再現しやすくしていない場合は、クローズされます。
このドキュメントでは、Expressプロジェクトのセキュリティ手順と一般的なポリシーについて説明します。
Expressチームとコミュニティは、Expressのすべてのセキュリティバグを真剣に受け止めています。Expressのセキュリティを向上させてくれてありがとうござます。あなたの努力と責任ある開示に感謝し、あなたの貢献を認められるようあらゆる努力を尽くします。
セキュリティバグは、Readme.mdファイルのリードメンテナーにメールで報告してください。
レポートにタイムリーに対応できるよう、レポート全体がメール本文に含まれており、Webリンクまたは添付ファイルのみに含まれていないことを確認してください。
リードメンテナーは48時間以内にメールを確認し、48時間以内にレポートの処理における次の手順を示す詳細な返信を送信します。レポートへの最初の返信後、セキュリティチームは修正と完全な発表までの進捗状況を継続的に通知し、追加の情報やガイダンスを求める場合があります。
サードパーティモジュールのセキュリティバグは、モジュールを保守している個人またはチームに報告してください。
セキュリティチームがセキュリティバグレポートを受け取ると、プライマリハンドラーに割り当てます。この担当者は、以下の手順を含む修正とリリースプロセスを調整します。
このプロセスを改善する方法について提案がある場合は、プルリクエストを送信してください。