開源禮儀

思考您為何要貢獻於 OSP

在您開始為開源專案貢獻之前，問問自己為什麼要這樣做。如果這個問題的答案是“我想找點事做”，那也很好，但更好的原因可能包括：

• 我想提升我的技能。
• 我一直在使用這個工具，發現了一個 bug，或者我想讓它變得更好。
• 我想幫助其他人更成功地使用這個工具。
• 我想幫助其他人更成功地為專案做出貢獻。
• 我想為我的大學課程公開展示我的技能，或者提高我獲得工作的機會。

這些原因中有一些是出於個人目的，這沒關係！擁有清晰的貢獻原因將使您更有效率，也更容易與社群合作。

保持禮貌，保持友善，避免煽動性或冒犯性語言

我們可以將這一點縮寫為“保持友善”。這是我們給任何開始貢獻開源的人的首要建議。對專案中的其他貢獻者保持友善，這將使這裡成為一個更愉快、更高效的地方。

• 如果有人幫助了您，請感謝他們。
• 在適當的時候祝賀別人，比如他們成功合併了一個拉取請求 (pull request)，或者修復了一個棘手的 bug。
• 始終以尊重的態度回應，即使您覺得問題的答案很明顯，或者有人在重複同樣的事情。
• 嘗試以支援的方式幫助人們做得更好。例如，說“這是錯的”或“答案在這裡”不如說“這樣可以，但我認為如果這樣做會更好，這裡有一篇部落格文章供您參考更多想法”或者“您可以在這裡找到答案；也可以看看這個連結，瞭解更多常見問題的答案”。

貢獻者之所以在這裡，是因為他們想對專案產生積極影響。除此之外，不要做任何假設，例如：

• 對專案及其構建所用技術的瞭解程度
• 性別、性取向、年齡、所講語言、地點、政治觀點、宗教或其他個人屬性
• 開源專案經驗
• 自信程度
• 期望
• 幽默感

您應該讓您寫的內容保持在主題之內，並避免爭議性話題，如宗教或政治。避免使用髒話或潛在的冒犯性語言。這些很少能改善溝通，反而會使他人更難參與。

即使您不同意某人或不喜歡他們做出的決定，也要保持支援和尊重。請注意，任何好的 OSP 都會制定規則來保護其貢獻者，使其在貢獻過程中不會感到不適。這通常可以在 GitHub 的 CODE_OF_CONDUCT.md 檔案中找到（例如，請參閱 mdn/content CODE_OF_CONDUCT）。

MDN 的倉庫遵循廣泛的 Mozilla 社群參與指南 (CPG)。在 MDN Web Docs 倉庫中，通常輕微冒犯性的行為（例如，持續跑題/搗亂，或不禮貌）將首先受到警告，然後是最後警告，接著是暫時或永久封禁。更嚴重的品行問題，如仇恨言論或威脅其他貢獻者，將不被容忍，並很可能導致立即封禁。

如果您收到任何讓您感到不適的內容，您應始終使用行為準則中提供的機制進行舉報。

選擇有效的貢獻

思考您想在專案上做什麼。例如，我們在 貢獻者任務看板 上列出了大量問題，按不同任務型別進行了分類。您也可以透過開啟 拉取請求 來修復您在閱讀 MDN 文章時遇到的問題。

MDN 的許多工作圍繞著編寫文件和程式碼示例，但也有其他貢獻方式。這可能包括幫助分類收到的問題、修復拼寫錯誤、糾正語法以使頁面更容易理解，或者指導那些試圖進行修復的人。每一次修復都有用，無論大小，我們都不會拒絕。不過，請儘量確保您的修復是有效的。我們建議避免以下型別的貢獻：

• 更新程式碼風格、文字語言或測試框架，僅僅因為您更喜歡它。
• 將頁面從美式英語改為英式英語。
• 在原始標點符號正確的情況下新增或刪除標點符號。

在許多情況下，OSP 的事物之所以如此，是有原因的。您應該閱讀它們可能提供的風格指南，如果您不確定某件事是否有效，請務必先詢問！

閱讀手冊

好的 OSP 總是會提供易於獲取的貢獻者文件。在 GitHub 專案中，它通常位於倉庫的 CONTRIBUTING.md 檔案中，有時也在專案的 README.md 檔案中。作為一個文件專案，MDN 內容本身有一個 README 和一套不錯的網站貢獻者文件（請參閱 社群資源）。

不要害怕尋求幫助，但在提問之前，請務必先嚐試自己找到答案。這樣，您就可以積累對專案的知識，變得更加獨立，並且不會給其他貢獻者帶來不必要的負擔。如果某個解釋很難找到或描述得不好，可以提交一個 issue，或者建立一個拉取請求來嘗試自己修復它。

找出哪裡可以提問

找出提問的最佳地點。好的 OSP 總是會在其文件中明確說明（請參閱 聯絡我們）。如果您想問一般性問題，請務必利用這些渠道。不要為每個問題都提交 GitHub issue，因為這會給專案增加噪音（請參閱下一節）。

創造進展，而非噪音

仔細考慮您在專案中的溝通方式 — 確保它是有效的，並且不會讓其他貢獻者的工作更困難。提交拉取請求來修復 bug 是很好的，但請確保它們是有效的或易於審查的。提交 issue 和參與其他對話都可以，但您的 issue 和評論是否切題，或者是否在製造噪音？

一般來說，請

• 每個 issue 討論一個主題 — 這樣可以輕鬆地使 issue 保持專注和高效。
• 每個 PR 修復一個問題 — 這對您來說可能稍微費力一些，但審查單個清晰的修復要容易得多。
• 如果您有有用的觀點或可以回答別人的問題，請參與其他討論串。
• 如果您不確定某件事是否有效，或者有一個簡單的問題，請使用聊天室或論壇等其他方式提問。
• 先閱讀手冊，嘗試自己回答問題，然後再提問。

請勿

• 試圖一次討論多個主題，或發表離題評論，使 issue 變得複雜。
• 試圖將多個修復合併到一個拉取請求中。這會大大增加審查難度，並引起懷疑（有些人可能會認為您試圖在有效更改中隱藏惡意程式碼）。
• 開啟大量 issue 來提問模糊的問題。
• 在沒有先嚐試自己解決問題的情況下提問。

OSP 是民主的（幾乎）

OSP 相當民主 — 許多決策會進行投票，並且您在很大程度上可以自由地以您想要的方式貢獻，只要您不阻礙任何人貢獻。

然而，有些事情將主要由一小群核心貢獻者決定。您可以自由地對任何決定提出反對意見，但有時版主會做出與您的意見相悖的決定。您需要尊重並接受這些決定。

瞭解任何專案的版主是有益的，這樣您就知道向誰尋求幫助最好，例如在拉取請求或 issue 討論串中。

保持耐心，保持及時

請記住，許多在 OSP 工作的人是在業餘時間無償工作的，而且所有在 OSP 工作的人通常都很忙。如果您正在等待諸如拉取請求審查或問題答案之類的事情，請保持耐心。

等待幾天，然後禮貌地提醒某人，詢問他們是否有時間檢視，這是合理的。如果他們碰巧太忙，最好再等一週，然後再嘗試跟進。

要求快速回復等事情是**不**合理或不禮貌的。

如果有人在等您為他們做某事，您也應該受到同樣的禮遇，但同時，請儘量儘快回覆。如果您實在抽不出時間，請告知他們，並請求維護者幫助您找到其他人來完成這項任務。

另見

• 如何為開源專案做貢獻
• freeCodeCamp 的更通用的“如何為開源專案做貢獻”列表
• 開始為開源專案做貢獻
• Google 工程實踐文件 (google.github.io/eng-practices)