開源貢獻指南（中文）
開源貢獻指南（英文）
什麼是開源，為什麼要開源
那麼你正準備擁抱開源嗎？恭喜你，開源世界欣賞你的貢獻。接下來讓我們聊聊什麼是開源，我們為什麼要開源。
“開源”意味着什麼？
當一個項目開源後，意味着 不論什麼目的，所有人都可以浏覽，使用，修改和分發你的項目。 這些權限都是來自于開源協定.
開源非常的強大。因為它降低了使用的門檻，使新奇的思想得到快速的傳播。
來了解它如何工作，想象下你的朋友正在吃便當，這時你帶來了櫻桃派。
- 每個人都會想要櫻桃派（使用）
- 這個派引起了一場轟動！周圍的人會想知道你的烹饪方法（浏覽）
- 有一位朋友Alex是一名糕點師，他會建議少放一點糖（修改）
- 另外一位朋友Lisa要求使用它作為下個星期的晚餐（分發）
同樣的，閉源就像是你去餐廳必須付錢才能吃櫻桃派。但是，餐廳不會告訴你櫻桃派的烹饪方法。如果你恰好抄襲了他們的派，并以你自己的名義出售，那麼餐廳将會采取行動抵制你。
人們為什麼要将他們的工作開源？
我從開源使用和協作中獲得的最有價值的經驗之一來自我與其他面臨許多相同問題的開發者建立的關系。
— @kentcdodds, "How getting into Open Source has been awesome for me"
這裡列舉了很多理由 來解釋為什麼個人或者組織想要開源自己的項目。下面列舉了部分：
- 協作: 開源項目歡迎所有人參與。例如， Exercism是一個有超過350人協作開發的練習程式設計的平台。
- 采用和重新混合: 任何人可以出于幾乎任何目的使用開源項目。人們甚至可以将開源項目用于建構其他的項目。例如， WordPress是基于開源項目 b2建構的。
- 透明度: 所有人都可以檢查開源項目中存在的問題。透明度對于政府（如 保加利亞 或者 美國）, 産業調整（如銀行業或者醫療健康行業）, 和軟體安全（如 Let's Encrypt）。
不僅僅是可以開源軟體，你可以開源一切，從資料集到書籍。通過浏覽 GitHub Explore 你可以知道什麼東西可以被開源。
開源是否意味着免費?
開源最吸引之處就是它不用花錢。然而免費隻是開源的價值的一個副産品。
因為 開源協定要求開源項目可以被任何人出于幾乎任何目的使用，修改和分享，這些項目一般都是免費的。如果有些開源項目需要付費使用，任何人都可以合法地使用其免費版。
結果是大多數開源項目都是免費的。但免費并不屬于開源定義的一部分。開源項目可以通過雙重許可協定或者其它的方法進行間接收費，同時不違背開源的官方定義。
我應該發起屬于自己的開源項目嗎?
答案是肯定的，因為不論結果是什麼，發起一個屬于自己的開源項目是學習開源最好的方法。
如果你還沒有開源過一個項目，你可能會因為沒有人關注或者别人的說辭而緊張。如果真是這樣的話，你并不孤獨！
開源與其他有創意的活動是一樣的，無論是寫作還是畫畫。你可能會害怕向世界分享你的工作，但練習是唯一讓你變得更好的方法，即使你沒有一位聽衆。
如果你不确信，那麼請花一點時間想想你的目标可能是什麼。
設定你的目标
目标可以幫助你知道該做什麼，不因該說什麼和需要從他人那裡獲得哪些幫助。請開始問自己，我為什麼要開源這個項目？
這個問題沒有一個正确的答案。你可能為一個簡單的項目設定了多個目标，或者不同的項目有不同的目标。
如果你唯一的目的是炫耀你的工作，你可能甚至不想将它貢獻出去，甚至不會在README中說明。另一方面，如果你想貢獻自己的項目，你将會花更多的時間在書寫簡潔明了的文檔上，使新來的參與者感到歡迎。
在某一時刻，我建立了一個自定義的UIAlertView，并且決定開源。是以我對進行了一些修改使其更加動态靈活，同時上傳到GitHub。我編寫了一份技術文檔以便其他開發者将UIAlertView用于他們的項目中。或許沒有人使用這個項目，因為這是一個簡單的項目。但是我為自己的貢獻感到開心。
— @mavris, "Self-taught Software Developers: Why Open Source is important to us"
随着你的項目的發展，你的社群可能不僅需要你提供的代碼。回複issues，審查代碼和傳播你的項目在一個開源項目中都是非常重要的任務。
雖然你花費在非編碼上的時間取決于項目的規模和範圍，但你應準備好作為維護者來自己解決問題或者向他人尋求幫助。
如果你參與了公司的開源項目， 確定你的項目擁有它所需要的内部資源。當項目啟動後，你會想知道由誰負責維護和在你的社群如何分享這些任務。
如果你需要為項目的宣傳，操作和維護準備一筆專用預算或者人員配置，那麼盡早開始讨論。
一旦你開源項目後，最重要的是你要考慮到項目周圍社群的貢獻和能力。你不必擔心一些不是你公司的貢獻者參與到項目的關鍵部分。
— @captainsafia, "So you wanna open source a project, eh?"
為其他的項目做貢
如果你的目标是想學習如何與他人一起協作或者了解開源是如何工作的，那麼你可以考慮為一個已存在的項目做貢獻。開始參與你曾經使用過和喜愛的項目。為項目做貢獻就像修改錯别字或者更新文檔一樣簡單。
如果你不知道如何開始做一個貢獻者，那麼可以閱讀我們的Github開源項目貢獻指南。
發起屬于你的開源項目
如果沒有充足的時間來開源你的工作，你可以開發一個想法，一個正在進行的工作或者多年後将被關閉的資源。
一般來說，當你發現有人對你的工作回報了一些有建設性的觀點後，你應該開源你的項目。
無論你決定開源你項目的哪個階段，每個項目都應該包含這些文檔：
- opensource license
- README
- opensource guidelines
- code of conduct
作為一名維護者，這些組合将會有助于你表達想法，管理貢獻和保護每個人的合法權益（包括你自己的）。他們大大增加了你獲得積極經驗的機會。
如果你的項目在GitHub上，将這些檔案按上面推薦的命名方式放在你的根目錄，這樣對你的讀者會一目了然。
選擇協定
開源協定可以保障他人對你的項目進行使用，複制，修改和貢獻時不會産生影響。它還保護你免受法律的困擾。當你發起一個開源項目時必須選擇一個協定。
法律工作很乏味。好消息是你可以在你的倉庫中使用一個已經存在的開源協定。這樣你隻花了很少的時間，但很好的保護了你的工作。
MIT, Apache 2.0, and GPLv3 都是非常流行的開源協定，但是 還有其它的開源協定 可供你選擇。
當你GitHub上建立了一個新項目，你可以選擇許可協定。包括可以使你的GitHub項目開源的協定。
如果你還有其它的疑問或者與開源項目相關的法律問題，請來這裡。
編寫README
READMEs不僅解釋了如何使用你的項目，他們還解釋了你的項目為什麼重要，以及使用者可以用它做什麼。
在你的README中盡量要回答以下的問題：
- 這個項目是做什麼的？
- 為什麼這個項目有用？
- 我該如何開始?
- 如果我需要使用它，我能從哪裡獲得更多幫助。
你可以用README去回答其它的問題，像你如何處理貢獻，項目的目标是什麼，開源協定的相關資訊。如果你的項目不想接受貢獻，或者你的項目不能用于産品，你就可以将這些寫在README中。
一份好的文檔意味着會吸引更多的使用者，收到更少的支援請求，得到更多的貢獻。（···）請記住你的讀者們不是你。參與同一個項目的開發者們有着完全不同的經曆。
— @limedaring, "Writing So Your Words Are Read (video)"
有時候，人們不會去編寫README。因為他們覺得項目還沒有完成或者他們不想要貢獻。這些都是非常好的為什麼要編寫README的理由。
為了獲得更多的靈感，可以嘗試使用 @18F's "編寫可閱讀的READMEs" 或者 @PurpleBooth's README 模闆去編寫一份README。
當你的根目錄中包含README檔案後，README就會顯示在GitHub倉庫的首頁上。
編寫你的貢獻指南
一份CONTRIBUTING檔案能否告訴你的粉絲如何參與你的項目。例如，檔案中可能會包含如下資訊：
- 如何報告bug (盡量使用 issue 和 pull request 目标)
- 如何提議一個新特性
- 如何建立你的開發環境和運作測試
另外技術清單和一份CONTRIBUTING檔案是一個你向貢獻者傳達你的期望的機會。如：
- 你渴望得到什麼類型的貢獻
- 項目的發展路線或者期望
- 貢獻者應該如何聯系你
使用溫暖，友好的語氣，并提供具體的建議（如寫作文檔或做一個網站）可以很大程度上讓新來者感到歡迎和興奮參與。
例如，Active Admin starts its contributing guide with:
首先，感謝你考慮為Active Admin做貢獻。就是因為有了像您這樣的人讓Active Admin成為了一個偉大的工具。
在項目的早期，你的CONTRIBUTING檔案會比較簡單。為了做出貢獻，你應該總是解釋如何報告bugs或者檔案issues和一些技術要求（像測試）。
過了一段時間，你肯會把頻繁出現的提問添加到CONTRIBUTING檔案中。寫下這些資訊意味着會有更少的人再重複向你提相同的問題。
想獲得更多書寫CONTRIBUTING檔案的幫助，請查閱 @nayafia's 貢獻指南模闆 or @mozilla's "如何建立 CONTRIBUTING.md".
在README中附上CONTRIBUTING檔案的連結，這樣會讓跟多的人看到。如果你 将CONTRIBUTING檔案放在項目的倉庫中,GitHub會自動連結你的檔案當貢獻者建立一條issue或者打開一個pull request。
制定行為規則
我們有過這樣的經曆，我們面臨什麼是濫用，或者作為一名維護者試圖解釋為什麼有些事必須按一定的方式，或者作為一名使用者提出簡單的問題。(...) 一份行為規則會變成一份簡單的參考和可連結的表示你的團隊提出的建設性的話語非常認真的文檔。 — @mlynch, "Making Open Source a Happier Place"
最後，一份行為規則幫助你為你項目的參與者建立了行為準則。如果你為一個社群或者一家公司發起一個開源項目，它是非常有價值的。一份行為規則授權你促成健康，有建設性的社群行為，這回減輕你作為一名維護者的壓力。
想獲得更多資訊，請查閱我們的 行為規則指南.
除了溝通如何期望參與者行為之外，行為準則還傾向于描述這些期望适用于誰，何時應用，以及如果違規發生時該做什麼。
許多開源協定一般也會為行為規則制定标準，是以你可以不用再編寫。這份貢獻者盟約 是一份被超過40,000個開源項目所使用的行為規則，包括 Kubernetes, Rails和Swift。無論你使用哪個文本，在必要的時候你都應該執行你的行為規則。
将文本直接粘貼到你倉庫中的CODE_OF_CONDUCT檔案中。将檔案放在項目的根目錄中友善查找，同時在README中添加相應的連結。
命名和品牌化你的項目
品牌不僅是一個華麗的logo或者易記的項目名。它還關于你如何談論你的項目，以及你想把資訊傳遞給誰。
選擇正确的名字
選擇一個容易記住，有創意，能表達項目用意的名字。例如：
- Sentry 監控應用程式的崩潰報告
- Thin 是一個簡單快速的Ruby web伺服器。
如果你的項目是基于一個已存在的項目建立，那麼使用他們的名字作為你項目名的字首會幫助你闡述你項目的用途。 (例如 node-fetch将
window.fetch
添加到了 Node.js)。
考慮闡明所有。押韻雖然有趣，但是記住玩笑不可能轉變成其它的文化，或者他人與你有不同的經曆。你的一些潛在使用者可能是公司員工，你不能讓他們在工作中很難解釋你的項目！
避免命名沖突
檢視是否有同名的開源項目，尤其是你分享的是同樣的語言或者生态系統。如果你的名字與一個已存在的知名的項目有沖突，你會讓你的粉絲感到困惑。
如果你想要一個網站，Twitter賬号或者其他特性來展示你的項目，先確定你能得到你想要的名字。理想情況下，為了美好的未來現在保留這些名字，即使你現在不想用他們。
確定你的項目名沒有侵權。如果有侵權，可能會有公司要求你的項目下架，或者對你采取法律措施。這樣得不償失。
你可以查閱WIPO全球品牌資料庫避免商标沖突。如果你是在公司工作，法律團隊會幫你做這件事。
最後，去谷歌搜尋你的項目名。大家會很容易地找到你的項目嗎？在搜尋結果禮是否有你不想讓大家看到的東西？
你的寫作（和代碼）如何影響你的品牌
在項目的整個生命周期中，你需要做很多文字工作：READMEs，教程，社群文檔，回複issues，甚至肯能要處理很多來信和郵件。
是否是官方文檔或者一封普通的郵件，你的書寫風格都是你項目品牌的一部分。考慮你可能會擁有粉絲，以及這是你想傳達的聲音。
我嘗試處理每一個細節，包括：處理郵件，展示示例，友好待人，認真處理大家的issues以及試圖幫助到大家。經過一段時間後，大家可能不再是隻問問題，還會幫助我解決其他人的疑問以及給我喜悅，他們模仿我的風格。
— @janl on CouchDB, "Sustainable Open Source"
使用熱情，通俗易懂的語言（如“他們”，即使是指一個人）能夠讓新來的貢獻者感覺項目非常歡迎他們。使用簡單的語言，因為你的讀者可能英語不是很好。
除了書寫風格外，你的編碼風格也是你項目品牌的一部分。 Angular 和 jQuery是兩個項目代碼風格嚴謹的示例和指南。
當你的項目才開始時，沒有必要為項目編寫一份風格指南。你可能會發現你喜歡将不同的編碼風格融入到項目。但是你應該想到你的書寫和編碼風格會吸引或者拒絕不同類型的人。項目的早期是你建立你希望看見的先例的機會。
你的預釋出清單
準備好開源你的項目了嗎？有一份幫助檢查清單。檢查所有内容？你準備開始吧！ 點選 "publish" 以及拍下自己的後背。
文檔
- 需要為項目指定一個開源協定
- 項目要有基礎文檔 (README, CONTRIBUTING, CODE_OF_CONDUCT)
- 易記的項目名，指出項目是做什麼的，不能和已存在的項目沖突或者商标侵權
- 最新的issue隊列，組織和标記清除的issues
代碼
- 項目使用一緻的代碼風格和明确的功能/方法/可用的名字
- 注釋清晰的代碼，記錄意圖和邊緣案例
- 在修改曆史，issues或者 pull requests 中沒有敏感的資訊 (例如 密碼或者其他不能公開的資訊)
人
如果你是代表個人：
- 你已經告訴了你的法律部門，以及/或者了解了你公司（如果你是某一家公司的員工）的開源政策和IP
如果你有一家公司或者組織：
- 你已經告訴了你的法律部門
- 你有一個宣布和促進項目的營銷計劃
- 一些人被允許管理社群互動（回複issues，檢查和合并pull requests）
- 至少有兩人管理通路項目
你做到了！
恭喜你開源了你的首個項目。不論結果如何，對開源社群都是一份禮物。随着每次commit,comment和pull request，你正在為自己或者他人創造學習和成長的機會。
轉載于:https://my.oschina.net/u/2501837/blog/854028