黑人生命也是命。
支持平等正義倡議.

為 Express 貢獻

Express 和 GitHub 上的 expressjs 組織 中的其他專案都是 Node.js 基金會 的專案。這些專案受 Node.js 基金會的通用政策和準則以及以下額外準則所規範。

技術委員會

Express 技術委員會由積極的專案成員組成,並指導 Express 專案的開發與維護。如需更多資訊,請參閱 Express 社群 - 技術委員會

社群貢獻指南

此文件旨在建立一個貢獻流程,其

詞彙

記錄問題

針對您可能遇到的任何問題或問題記錄問題。如有疑問,請記錄問題,任何關於要包含內容的其他政策將在回應中提供。唯一的例外是應私下發送的安全揭露。

提交者可能會將您引導至另一個儲存庫,要求進一步澄清,並在處理問題之前加入適當的元資料。

請保持禮貌和尊重。預計每位參與者都應遵守專案的行為準則。

貢獻

此儲存庫中資源的任何變更都必須透過拉取請求進行。這適用於文件、程式碼、二進位檔案等的所有變更。即使是長期提交者和 TC 成員也必須使用拉取請求。

沒有拉取請求可以在未經審查的情況下合併。

對於非瑣碎的貢獻,拉取請求應至少放置 36 小時,以確保其他時區的貢獻者有時間進行審查。還應考慮週末和其他節假日,以確保活躍的提交者在希望參與討論和審查流程時,都有合理的時間參與。

每個貢獻的預設值是,一旦沒有提交者提出異議,則表示接受。在審查期間,提交者也可以要求在特定領域最精通的特定貢獻者在 PR 合併之前提供「LGTM」。對於登陸的貢獻,沒有額外的「簽名」流程。一旦提交者提出的所有問題都得到解決,任何提交者都可以登陸。

如果其他提交者在拉取請求中提出異議,所有相關提交者都應通過討論、對提議的變更進行妥協或撤回提議的變更來解決所表達的疑慮,以達成共識。

如果某項貢獻有爭議,並且提交者無法就如何使其登陸或是否應該登陸達成共識,則應將其升級至 TC。TC 成員應定期討論待處理的貢獻,以找出解決方案。預計只有少數問題會提交至 TC 以尋求解決方案,並且提交者之間的討論和妥協將是預設的解決機制。

成為審查員

任何人都可以成為審查員!在 審查流程文件 中閱讀更多有關成為審查員的流程。

expressjs/express 儲存庫中開啟一個問題 以請求審查角色。說明您已閱讀並同意 行為準則 和角色詳情。

以下是範例議題內容,你可以複製貼上

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

在你開啟議題後,TC 的成員會將你加入組織要求中的 triage 團隊。然後他們會關閉議題。

快樂地進行分類!

成為提交者

所有提交非瑣碎貢獻的貢獻者都應適時加入,並新增為提交者,並獲得儲存庫的寫入權限。

預期提交者遵循此政策,並持續發送拉取要求、進行適當的檢閱,並讓其他提交者合併他們的拉取要求。

TC 程序

TC 對升級到 TC 的議題使用「尋求共識」的程序。該小組嘗試找出 TC 成員之間沒有公開反對意見的解決方案。如果無法達成沒有反對意見的共識,則會進行多數決投票。預期 TC 做出的多數決策都是透過尋求共識的程序,而投票僅作為最後的手段。

決議可能包括將議題退回給提交者,並提供有關如何朝向共識前進的建議。預期 TC 會議並非在會議期間解決議程上的所有議題,並可能更希望持續進行提交者之間的討論。

隨時可以新增成員至 TC。任何提交者都可以提名另一位提交者至 TC,而 TC 使用其標準的尋求共識程序來評估是否新增此新成員。預期未持續參與,且參與程度低於其他成員多數的成員會辭職。

協作者指南

網站議題

在 https://github.com/expressjs/expressjs.com 中開啟 expressjs.com 網站的議題。

公關和程式碼貢獻

分支

針對錯誤修正或次要工作(預計納入目前的發行串流),請使用 master 分支。

針對預計納入 Express 未來發行的任何內容,請使用對應命名的分支,例如 5.0

貢獻步驟

  1. 建立問題,說明您想要修正的錯誤或想要新增的功能。
  2. 在 GitHub 上建立您自己的 分岔,然後結帳您的分岔。
  3. 在您的本地副本撰寫您的程式碼。針對您處理的每個新問題建立一個分支是個好習慣,但並非強制規定。
  4. 若要執行測試套件,請先透過執行 npm install 安裝依賴項,然後執行 npm test
  5. 透過執行 npm run lint 確保您的程式碼經過 linted 處理,並修正您看到的任何問題。
  6. 如果測試通過,您可以將變更提交至您的分岔,然後從那裡建立一個 pull request。請務必在 pull request 留言中參考您的問題,並包含問題編號,例如 #123

問題類型為問題

我們通常會關閉任何含糊不清的問題或特定於您撰寫的某些應用程式的問題。在急於張貼問題之前,請務必仔細檢查文件和其他參考資料。

有助於讓您的問題獲得關注的事項

如果您發布問題,卻未說明上述項目或未讓我們輕鬆了解並重現您的問題,則會將其關閉。

安全政策和程序

本文檔概述了 Express 專案的安全程序和一般政策。

回報錯誤

Express 團隊和社群嚴肅看待 Express 中的所有安全錯誤。感謝您改善 Express 的安全性。我們感謝您的努力和負責任的揭露,並將盡一切努力肯定您的貢獻。

透過電子郵件寄送給 Readme.md 檔案中的主要維護人員,回報安全錯誤。

為了確保及時回應您的回報,請確保回報的全部內容包含在電子郵件主旨中,而不要只放在網頁連結或附件中。

主要維護人員將在 48 小時內確認您的電子郵件,並在 48 小時內傳送更詳細的回應,說明處理您的回報的後續步驟。在對您的回報做出初步回應後,安全團隊將努力讓您了解修復和完整公告的進度,並可能要求提供其他資訊或指導。

將第三方模組中的安全錯誤回報給維護該模組的人員或團隊。

揭露政策

當安全團隊收到安全錯誤回報時,他們會將其指定給主要處理人員。此人將協調修復和發布程序,包括以下步驟

對此政策的評論

如果您有關於如何改善此程序的建議,請提交拉取請求。