Issue 貢獻

當在 GitHub 組織中的任何儲存庫開啟新的 issue 或評論現有的 issue 時，請確保討論內容與 Sails.js 軟體的具體技術問題相關。我們隨時歡迎功能請求和想法，但不應將其作為 GitHub issue 提交。有關提交指南，請參閱下方的「請求功能」。

如需 Sails 的一般使用幫助，請參閱官方 Sails 文件。如需其他幫助，請在 StackOverflow 上提問，或參考任何其他推薦的支援管道。

如果您在 Sails 或其任何依賴項中發現安全漏洞，請勿在公開 issue 中報告。相反，請立即使用Sails 安全政策中詳述的說明，提醒核心維護人員。即使對於非 Sails.js 核心團隊直接維護的外部依賴項（例如 Socket.io、Express、Node.js 或 openssl），也請遵守此請求。無論您是否認為核心團隊可以採取任何措施來修復問題，請遵循我們的安全政策中的說明，盡快私下披露漏洞。

最後，關於非技術性質的討論，包括團隊成員資格、商標、行為準則以及關於專案的高層次問題或疑慮，應直接發送電子郵件至核心維護人員：[email protected]。

開啟 issue

Sails 由許多不同的子專案組成，其中許多專案都有其自己的專用儲存庫。即便如此，提交疑似 Sails 核心團隊維護的模組問題的最佳地點仍然是在主要的 Sails 儲存庫中。這有助於我們掌握 issue 並保持井然有序。

在提交 issue 之前，請遵循這些簡單的說明

首先，在主 Sails 儲存庫內的 GitHub 搜尋中搜尋與您的 issue 類似的 issue。

• 如果您的原始錯誤報告已包含在現有的開放 issue 中，請在該 issue 中新增評論，而不是開啟新的 issue。
• 如果所有明顯相關的 issue 都已關閉，請開啟新的 issue，並在底部貼上已關閉 issue 的 URL 連結。
• 如果您找不到任何相關的 issue，請嘗試使用不同的搜尋關鍵字（如果適用）（以防影響您的搜尋方式，在撰寫本文時，GitHub 使用基於 Lucene 的 ElasticSearch 來索引內容）。如果您仍然找不到任何相關的現有 issue，請建立一個新的 issue。
• 請考慮回溯連結的重要性。回應您的 issue 的貢獻者幾乎總是需要自行搜尋類似的現有 issue，因此將所有 URL 放在一個地方可以節省大量時間。另請記住，從新的 issue 回溯連結會使 GitHub 自動在引用的原始 issue 中插入指向新 issue URL 的連結。這非常有幫助，因為許多訪問我們 GitHub issue 的訪客都是從搜尋引擎來的。

一旦您確定應該建立新的 issue，

• 請確保您的新 issue 沒有報告多個不相關的問題。

  • 如果您遇到多個問題，並且這些問題明顯不同，請為每個問題建立單獨的 issue，但從最緊急的問題開始。
  • 如果您遇到多個相關問題（您只能同時重現的問題），請僅建立一個 issue。但請務必徹底描述這兩個問題，以及導致它們都出現的必要步驟。

• 檢查您的 issue 是否有一個簡潔、切題的標題，標題使用禮貌、中性的語言，在可用空間內盡可能清楚地解釋問題。您的 issue 的理想標題是能夠一目了然地傳達問題的標題。

  • 例如，「在 lift 時，jst.js 從 layout.ejs 中移除」是一個非常有幫助的 issue 標題。
  • 以下是一些非範例——也就是說，沒有幫助的 issue 標題範例
    • 「templates dont work」：這個標題太過模糊。即使無法收集更多資訊，像「templates 出現非預期行為」這樣的措辭也更具體一點，並且可能會更快獲得回應。
    • 「app broken cannot access templates on filesystem because it is broken in the asset pipeline please help」：這個標題重複且包含不必要的內容（「please help」）。請記住，有用的標題既具描述性又簡潔。
    • 「jst.js is being REMOVED!!!!!!!!!!!!!」：這個標題包含不必要的大寫和標點符號，輕則令人分心，重則可能被認為是不禮貌的。無論如何，這不太可能加速對您的 issue 的回應。
    • 「How does this dumb, useless framework remove jst.js from my app?」：這個標題包含不必要的負面情緒，這不利於參與者審閱。為了獲得最佳的 issue 解決體驗，請盡量保持標題客觀。
    • 「Thousands of files being corrupted in our currently deployed production app every time the server crashes.」：像這樣的語言可能被認為是誇張的，並可能降低您的聲明的可信度。在這種情況下，它甚至可能會混淆問題（例如，「這是否僅在 NODE_ENV===production 時發生？」）。

• 在整理重現 issue 的步驟之前，請盡可能標準化您個人開發環境上的變數

  • 確保您 lift 的應用程式是正確的。
  • 確保您已使用 CTRL+C 終止 Sails 伺服器並重新啟動。
  • 確保您沒有任何瀏覽器標籤頁指向 localhost。
  • 確保您沒有任何其他 Sails 應用程式在其他終端視窗中執行。
  • 確保您用於重現 issue 的應用程式具有乾淨的 node_modules/ 目錄，這表示
    • 沒有連結任何依賴項（例如，您沒有執行 npm link foo）
    • 您沒有對 node_modules/ 資料夾中的檔案進行任何內聯變更
    • 您沒有任何奇怪的全域依賴迴圈。如果您不確定以上任何一項，最簡單的雙重檢查方法是執行：rm -rf node_modules && npm cache clear && npm install。

• 請記住提供您的應用程式正在使用的 Sails 版本 (sails -v)。

  • 請注意，這可能與您全域安裝的 Sails 版本不同。

• 提供您目前安裝的 Node.js 版本 (node -v)、您的 NPM 版本 (npm -v) 以及您正在執行的作業系統（OS X、Windows、Ubuntu 等）。

  • 如果您使用 nvm 或另一個 Node 版本管理器（如 n），請務必在 issue 中提及。

• 從乾淨的 Sails 應用程式（即在沒有特殊環境變數或 .sailsrc 檔案的電腦上使用 sails new 建立的應用程式）提供重現問題的詳細步驟

• 最後，花一點時間思考您即將發布的內容以及 Sails 使用者群體的其他成員將如何解讀它。確保它符合我們的行為準則，並確保您沒有透過公開發布安全漏洞來危害其他 Sails 使用者。

不符合這些準則的 issue 通常會在未經閱讀的情況下關閉，並附帶要求提交者查看本貢獻指南的回應。如果這種情況發生在您身上，請意識到這並非針對個人，甚至可能再次發生。請理解 Sails 是一個大型專案，每個月收到數百個新的 issue 提交，我們非常感謝您花時間發布詳細的 issue。您越熟悉本貢獻指南中規定的慣例和基本規則，您未來的貢獻對社群就越有幫助。您也將贏得核心團隊成員的尊重，並為未來的貢獻者樹立良好的榜樣。

您可以將這些規則視為美麗山路上面的護欄：它們可能並不總是美觀，如果您撞到它們，您可能會受到一點撞擊，但是，總體而言，它們可以防止我們所有人滑出彎道並墜入深淵。