diff --git a/_articles/zh-tw/README.md b/_articles/zh-tw/README.md
new file mode 100644
index 00000000000..b080300899e
--- /dev/null
+++ b/_articles/zh-tw/README.md
@@ -0,0 +1,16 @@
+# 開源軟體指南 繁體中文
+
+[開源軟體指南](https://opensource.guide/) 是一份給個人、開源社群或是公司希望學習如何運行和貢獻開源項目的資源指南。
+
+## 貢獻
+
+網站是由[Jekyll](https://jekyllrb.com/) 套件建立而成。請先閱讀 [貢獻指引](https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.md) 來了解如何回饋以及貢獻。
+
+## 授權
+
+內容以 [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/) 的方式釋出。請參閱 [notices](https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.md) 文件以了解歸音指南、貢獻條款、軟體以及第三方授權權限。
+
+## 人員致謝
+
+1. [opencc](https://github.com/BYVoid/OpenCC): 協助繁簡體字轉換簡化翻譯效率。
+2. [tmonk](https://github.com/felixshai): 致力彙整維護翻譯。
diff --git a/_articles/zh-tw/best-practices.md b/_articles/zh-tw/best-practices.md
new file mode 100644
index 00000000000..f5322453660
--- /dev/null
+++ b/_articles/zh-tw/best-practices.md
@@ -0,0 +1,269 @@
+---
+lang: zh-tw
+title: 維護者最佳實踐
+description: 身為開源的維護者，如何輕鬆駕馭專案？本指南從文件流程到有效利用社群來展開。
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+ - metrics
+ - leadership
+---
+
+## 身爲一名維護者意味著什麼?
+
+如果你維護著一個非常流行的專案，你可能就會意識到自己寫程式的時間變少，而花費在回答issue的時間越來越多。
+
+在專案的起步階段，你會不斷嘗試著實現自己的新想法，也能夠基於自己想要的作出決定。隨著專案越來越受歡迎，就會發現你大部分的時間都花在了與用戶、貢獻者打交道上。
+
+維護一個專案需要的不僅僅是寫程式的能力。有些時候會有一個你意想不到的的事情要應付，但是這對一個專案的成長也很重要(相對於寫程式來說)，我們收集了一些小技巧來讓你的維護工作變得稍輕鬆些，這些技巧，涉及範圍頗廣，從寫文件到管理社群都有所涉獵。
+
+## 將流程文件化
+
+對於一個專案的維護者來說寫文件是最重要的事情之一。
+
+文件不僅說清楚了你的想法是什麼，還能幫助別人在問問題之前理解你需要什麼和接下在希望做什麼。
+
+將一些東西寫下來，當遇到不符合專案預期的內容時，可以輕鬆的拒絕。同時，它對於人們的參與和提供幫助提供了指導。最有意思的是，撰寫文件的人可能永遠也不知道是誰讀了他寫的文件，或者使用專案。
+
+即使你不想長篇大論，對要點略說一二也比啥都不寫要好。
+
+### 寫下你的專案的發展方向
+
+請在專案啓動時就寫下專案目標，並將之加到 README 文件中，或者創建一個單獨的 **VISION** 文件，其它還能幫助人們瞭解這方面的訊息如專案管理路線圖，最好是也把他們公開。
+
+有一個明確的，用文件表達清晰的願景，能保證專案的走向不會跑偏，同時也能保障不會因爲其他的貢獻者增加的奇怪的需求而使專案變質。
+
+比如，@lord 發現專案有一個明確的願景能夠幫助他決定哪個 PR 值得花時間。作爲一個維護者的新手，他甚至還後悔當他接到第一個關於[slate](https://github.com/lord/slate)PR的時候沒有堅持專案本身的原則。
+
+
+
+### 和大家交流你自己對專案的期望
+
+制定規則是很傷腦筋的。有時候你可能覺得你像是在限制別人的行爲或者說把好玩的東西都搞沒了。
+
+制定了規則，然後嚴格執行，當然啦，好的規則會讓維護者更輕鬆。他們會把你從做自己不願意做的事情中解脫出來。
+
+大多數知道你專案的人對你或者你的處境都是一無所知。他們可能會覺得你做這個專案是有錢拿的，特別是你的專案是他們經常用的而且某種程度上有點依賴的時候。其實你只是在有時候會在專案上花很多時間，但是現在你在忙著安置新工作或者照顧剛出生的兒子。
+
+這些都是再正常不過的事情！所以確保讓別人也知道這些。
+
+如果你維護某個專案是利用空閒時間或者完全自願的，能花多少時間就花多少時間。而不是你覺得專案需要你花多少時間或者別人想讓你花多少時間。
+
+這裡是一些值得你寫進專案裡的東西：
+
+* 怎樣的貢獻會被複查和接受(_需要測試嗎？提Issue有模板嗎？_)
+* 你本人會接受什麼類型的貢獻？（_你是不是只希望在某些部分的程式上需要別人的幫助？_）
+* 在合適的時候跟進專案（比如說 _如果你在七天之內沒有收到maintainer的回覆，而且依舊沒有其它任何人的回應，那麼就直接找他/她。_）
+* 你會在這個專案上話多少時間（比如說 "_我們每星期只會在這個專案上花5個小時_"）
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs)、[CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules)、以及 [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) 均是爲維護者和貢獻者提供了很好的基本規則的專案，乃業內典範。
+
+### 保證交流是公開進行的
+
+不管是什麼時候，保證你的交流是在公共的場所（就是大家都能看到的地方）。如果有人嘗試和你私聊，哪怕是討論一個新的需求或者功能，請禮貌的引導他/她到公共的交流場所，比如郵件列表或者issue tracker。
+
+如果你和別的維護者面談了，或者在私下做了一個很重要的決定，把這些訊息告訴大家，即使只是把你的筆記發上去。
+
+這樣的話，每個人新加入到你們社群的人和已經待了多年的人能夠瞭解到的訊息是一樣的。
+
+## 學會拒絕他人
+
+把所有的事情都寫下來，當然，對你執行你制定的規則的時候客觀分析實際情況也有幫助。
+
+拒絕別人確實不是很好玩，但是也要表現出專業程度，比如使用"你的貢獻不符合這個專案的標準"而不是"我不喜歡你的貢獻"這樣顯得粗魯的語句。
+
+作爲一個維護者，在很多情況下，你都要拒絕別人：不符合專案規則的PR, 某個人脫離了討論的重點，給別人做無關緊要的工作等等。
+
+### 保持友好溝通
+
+你要學會拒絕的最重要的地方就是Issue和PR請求。作爲一個專案的維護者, 你會不可避免的收到你不想接受的建議。
+
+可能某個貢獻並不在專案的範圍或者和你的期望不合。又或者是可能想法很好，但是實現的卻很爛。
+
+不管是什麼原因，在處理這些不符合專案標準的貢獻的時候都要婉轉。
+
+如果你收到了你不想接受的貢獻，你的第一反應可能是忽略或者假裝沒看到。但是這麼做會嚴重傷害到別人而且可能會讓你社群裡的其他貢獻者失去動力。
+
+
+
+別因爲自己感到內疚或者想做一個好人就把你不想接受的貢獻繼續保留。隨著時間的流逝，這些你沒有回答的issue和PR會讓你覺得很不爽。
+
+更好的方式是馬上關掉你不想接受的貢獻。如果你的專案已經飽受積壓的issue的折磨，@steveklabnik 可以給你點建議，[如何高效率的解決issue](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)。
+
+第二點，忽略別人的貢獻等於是在社群傳遞了一個負面的信號。讓人感覺提交一個貢獻是蠻恐懼的事情，尤其是對於剛加入的新手來說。即使你不接受他們的貢獻，告訴他們爲什麼然後致謝。這會讓人覺得更舒服。
+
+如果你不想接受某個貢獻：
+
+* **感謝他們** 的貢獻
+* **解釋爲什麼他們的貢獻不符合** 專案的需求範圍，然後提供清楚的建議以供改善，如果你可以的話。和藹一點，但同時也要講原則。
+* **引用相關的文件，** 如果你有的話。如果你發現你反覆收到你不想接受的貢獻，把他們加到文件以免你重複敘述。
+
+你不需要用超過1-2兩句話來回覆。比如，當一個[celery](https://github.com/celery/celery/)的用戶報告了一個window相關的錯誤，@berkerpeksag 是[這麼](https://github.com/celery/celery/issues/3383)回覆的
+
+
+
+如果你感覺拒絕別人很不好意思，也很正常，其實很多人都是這樣。就像 @jessfraz [說到的](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> 我和很多來自諸如Mesos, Kubernetes, Chromium等不同開源專案的維護者交流過，他們都異口同聲的覺得做一個維護者最難的就是拒絕你不想要的補丁。
+
+對於不想接受別人的貢獻這件事不要感到愧疚。如 [@shykes](https://github.com/shykes)[所說](https://twitter.com/solomonstre/status/715277134978113536)開源的第一原則就是 _"拒絕是暫時的，接受是永遠的。"_ 當然啦，認同別人的熱情還是一件好事，拒絕他的貢獻和拒絕他這個人是兩碼事。（要做到對事不對人。）
+
+最後，如果一個貢獻不是夠好，你沒任何義務接受它。對那些想對你的專案做貢獻的人保持和藹和積極的態度，但是只能接受那些你確定會讓你的專案變得更好的提交。你說拒絕的次數越多，對你來說拒絕別人就越容易。謹記！
+
+### 保持主動
+
+要想減少你不想接受的貢獻的數量，首先，在你專案的貢獻指南中解釋如何提交貢獻以及怎樣的貢獻會被接受。
+
+如果你收到太多低質量的貢獻，讓那個貢獻者先多做做功課，比如：
+
+* 填寫一個 issue 或者 PR 的模板/清單
+* 在提交PR之前先開一個 issue
+
+如果他們不遵從你的規則，馬上關掉 issue 並引用你的文件。
+
+當然啦，這麼搞一開始是不太舒服，但是你主動一點確實對雙方都好。它減少了某個人花了太多時間到一個你不想要的 PR 上的可能性。而且讓你管理起來更輕鬆。
+
+
+
+有時候，當你說不的時候，你潛在的貢獻者會感到對你的沮喪或者不爽。如果他們開始找你撕逼了，[採取必要的措施以應對局勢](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items)或者乾脆把他們從你的社群開除，如果他們不打算和你保持建設性的合作關係的話。
+
+### 成爲導師
+
+可能在你的社群裡有人不斷提交一些不符合專案需求的貢獻。對你們雙方來說，不停的拒絕他的提交，會令雙方都很尷尬。
+
+如果你發現有人對你的專案很上心，但是就是需要調教，那就耐心一點。給他解釋明白每次它的提交爲什麼不符合專案需求。嘗試著讓他先做一些簡單一點的事，比如那些標有 _"good first issue"_ 標籤的issue，以此讓他慢慢習慣。如果你有時間的話，考慮教他怎麼完成第一次的貢獻，或者在社區找一個人來負責。
+
+## 有效利用社群
+
+你不需要凡事親力親爲。這就是社群存在的原因！即使你沒有一個活躍的貢獻者社群，但是如果你有很多用戶的話，拉他們來幹活兒。
+
+### 分擔工作量
+
+如果你正在尋找其他人來參與，從身邊的人開始。
+
+當你看到新的貢獻者不停的提交貢獻，通過分配給他們更多任務來表示認可。如果別人願意的話，記錄下別人是怎麼成長爲領導者的過程。
+
+鼓勵別人來[一起管理專案](../building-community/#分享專案的所有權)能很大程度上減輕你的工作量，就像 [@lmccart](https://github.com/lmccart) 在他的專案上做的那樣，[p5.js](https://github.com/processing/p5.js)
+
+
+
+如果你需要暫時或者永久的離開的專案，請找人來代替你，這並沒有什麼不好意思。
+
+如果別人認同專案的發展方向，給他們提交的權限或者正式把專案所有權轉移給他。如果有人fork了你的專案而且在保持活躍的維護中，考慮在你的原始的倉庫放上這個fork版本的鏈接。如果大家都希望你的專案繼續的話這不失爲一種好辦法
+
+[@progruim](https://github.com/progrium) [發現](https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) 由於它給他的專案[Dokku](https://github.com/dokku/dokku)寫一個關於專案發展方向的文件，即使在它離開這個專案後他的那些目標仍然會被實現。
+
+> 我寫了一個wiki來描述我想要啥和爲什麼。不知道爲啥，專案的維護者就開始推動專案朝這個方向發展，這對我來說還是有點驚訝的。他們會絲毫不差的按照我的意願去做這個專案嗎？不總是這樣，但是總是會把專案推動到離我的理想狀態更近的位置。
+
+### 讓別人嘗試他們自己想要的解決方案
+
+如果有貢獻者關於專案有不同的意見，你可以禮貌的鼓勵它在他自己fork版本上繼續工作。
+
+fork一個專案不什麼壞事情。能複製並且修改別人的程式是開源專案最大的好處之一。鼓勵你的社群成員在他自己fork的倉庫上繼續工作，這是在不和你的專案衝突的基礎上，給實現他們的想法最好的出口。
+
+
+
+這對於那些強烈的需要某個你沒時間實現的解決方案的用戶來說也是一樣的。提供API或者自定義的鉤子幫助他們更好的實現自己的需求而不需要改動源碼。[@orta](https://github.com/orta)[發現](https://artsy.github.io/blog/2016/07/03/handling-big-projects/)鼓勵在CocoaPods上使用插件導致了很多有趣的想法的誕生。
+
+> 一旦一個專案變大之後，維護者對怎麼增加新程式變得保守是不可避免的事情。你可能很會拒絕別人的需求，但是很多人提的都是合法的需求。所以，你不得不把你的一個工具變成平臺。
+
+## 使用機器人
+
+就像很多工作別人可以幫你做一樣，也有很多工作不需要人來做。因爲有機器可以替代人工，尤其是那些重複、無聊的工作，用好它們能夠讓你的維護生活變得更容易。
+
+### 引進測試和別的檢查來改善你的程式質量
+
+讓你專案自動化的最重要的方法之一就是引進測試。
+
+測試能夠幫助貢獻者自信他們沒有弄壞什麼。測試也讓你複查程式和接受別人的貢獻的過程更加容易。你反應的越多，社群參與的就越多。
+
+設置自動化的測試讓所有新來的貢獻者都可用，而且保證你的測試可以很容易在貢獻者的本地運行。保證所有的程式貢獻者在提交之前都運行你的測試。你還得爲所有的提交設置一個基本的標準。
+
+如果你添加了測試，確保在 CONTRIBUTING 文件裡面解釋他們是怎麼工作的。
+
+
+
+### 用工具來自動化日常的維護工作
+
+對於維護一個流行的專案來說，一個好消息是別的維護者也可能遇到過類似的問題而且已經找到一個解決方案。
+
+這裡有[各種各樣的工具](https://github.com/integrations)幫你自動化一部分的維護工作。這裡僅列舉一些常見的例子：
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) 自動化版本發佈
+* [mention-bot](https://github.com/facebook/mention-bot) 可能的貢獻者來幫你複查程式
+* [Danger](https://github.com/danger/danger) 幫你自動複查程式
+
+對於bug報告和其他常見形式的貢獻，Github有[Issue 模版和 Pull Request 模版](https://github.com/blog/2111-issue-and-pull-request-templates), 你可以用來降低溝通成本。你也可以設置[郵件過濾](https://github.com/blog/2203-email-updates-about-your-own-activity)來管理你的郵件提醒。
+
+如果你想更加的先進和高效，程式風格指南和linter能讓你專案收到的貢獻更加規範，而且更容易複查和被接受。
+
+當然啦，如果你的標準太複雜了，反倒會增加了貢獻的難度。所以保證你只添加那些讓每個人工作起來更容易的規則。
+
+如果你不確定用什麼工具，看一看別的流行專案是怎麼做的，特別是和你在一個生態系統的。比如，其他的Node模塊的貢獻流程是怎麼樣的？用相似的工具和方法，能夠讓你專案的貢獻流程對於開發者來說是很熟悉的。
+
+## 不幹了也沒關係
+
+開源專案曾經讓你開心，但可能現在開始讓你不開心了。
+
+可能當你想到你的專案的時候感覺到"亞歷山大"。而同時，issue和PR又紛至沓來。
+
+疲倦在開源工作工作中是一個常見的問題，特別是在維護者中間。作爲一個維護者，你做的開心對專案的生存來說是一個沒有商量餘地的條件。
+
+雖然你不需要跟誰請假，但是也不要拖到自己疲倦不堪的時候纔去度假。[@brettcannon](https://github.com/brettcannon)，一個python的核心開發者，決定在14年的義務勞動之後[休一个月的假](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)。
+
+就像其他工作一樣，有規律的休息會讓你對工作保持舒適愉快的心情。
+
+
+
+有時候，當你感覺大家都離不開你的時候，請假去休息是一件蠻困難的事情。甚至你自己會因爲離開而感到愧疚。
+
+在你離開專案的時候儘可能的在用戶和社群中間尋求支持，如果你找到支持你的人，還是休息吧。在你不工作的時候還是要保持和別人交流，這樣人們不會因爲你的失聯而感到奇怪。
+
+休假不僅適用於度假。如果你週末不想做開源專案的工作了，或者在本該工作的時候不想幹活了，和別人說，這樣他們知道什麼時候不該打擾你。
+
+## 首先照顧好自己！
+
+維護一個大型專案時，相比早期的增長階段，是需要更多的不一樣的技能，作爲一個維護者，你會將自己的領導力和個人能力提高一個層次，而這是很少人能體會的到的。但是與此同時，要挑戰管理專案，以及設定清晰的界限。只做你感到舒服的事情，能夠讓你保持開心，活力，高產的狀態。
diff --git a/_articles/zh-tw/building-community.md b/_articles/zh-tw/building-community.md
new file mode 100644
index 00000000000..23d14e782b3
--- /dev/null
+++ b/_articles/zh-tw/building-community.md
@@ -0,0 +1,280 @@
+---
+lang: zh-tw
+title: 打造友善、溫暖的社群
+description: 打造個人們願意使用、貢獻並願意主動宣傳的人氣社群。
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## 讓專案朝成功邁進
+
+現在的你，你已經啓動屬於你自己的專案，正在向世界介紹它，有人對你的專案感到好奇。這真是令人振奮！接下來要考慮的是，如何讓有興趣的人持續地待在這個社群裡。
+
+友善的社群對於專案的未來至關重要，如果你的專案開始有人願意貢獻，記得給這些先行者一個愉快的協作體驗，鼓勵他們持續參與。
+
+### 讓大家感到受歡迎
+
+@MikeMcQuaid 提供了一個思考專案社群的看法稱之為[貢獻者漏斗](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/)
+
+
+
+當你建立了自己的開源社群，想想這些處於漏斗上方的人（潛在用戶）是如何下潛到底部（活躍的維護者）。你的目標是減少貢獻者在每個階段所遇到的摩擦。當人們能從中輕易的獲得成就感時，就會樂意去做更多的事。
+
+從你的說明文件開始著手：
+
+* **讓大家很容易上手。** [一份好閱讀的 README](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#編寫readme)以及清晰的程式碼範例，讓大家很容易的上手。
+* **清楚的說明該如何貢獻**，使用[你的CONTRIBUTING file](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#編寫你的貢獻指南)並持續更新issues。
+
+在 [GitHub 2017 開源調查報告](http://opensourcesurvey.org/2017/)中指出，令人困惑或不完整的說明文件是開源使用者最大的困擾，好的說明文建會吸引人們與專案互動。總有一天，會有人開啟一個 issue 或 PR。盡量使用這些工具讓人們有機會朝漏斗的下方邁進。
+
+* **當有人選擇了你們的專案，記得對他們表示謝意！** 因為可能只是一次不愉快的經歷，就足以讓一些人再也不想回來。
+* **及時回應。** 如果一個月都沒有回答他們的 issue，他們可能也早就忘記了你們的專案。
+* **以開放的態度接受各式各樣的貢獻。** 很多貢獻者是從提報一份 bug 或者修一些小東西開始的。這裡有[很多為專案做貢獻的方式](../how-to-contribute/#具體而言什麼是貢獻)。讓大家選擇他們喜歡的方式。
+* **如果你不贊成一個貢獻。** 首先你需要對他們的想法表示感謝，同時 [解釋為什麼](../best-practices/#學會拒絕他人)這點子不適合專案，如果有必要的話你可以給出相關文件的連結。
+
+
+
+多數開源貢獻者是「不固定的貢獻者」，因為他們只是偶爾參與專案。一位不固定的貢獻者可能沒有充裕的時間全程參與你的專案，所以你的工作是能讓他們很輕鬆地參與貢獻。
+
+鼓勵其他的貢獻者也是對專案的一種投資。當你們授權大量的粉絲做他們感興趣的工作時，壓力就會少很多。
+
+### 記錄一切
+
+
+
+當你開始一個新專案，會覺得就私下默默地工作是很正常的。但開源專案真正開始茁壯的時候，是當你開始公開的把你的進度歷程紀錄下來的時候。
+
+把事情記錄下來，會更多的人參與，參與的人也方便能從歷程的每個階段著手。你甚至可能會得到意想不到的幫助。
+
+技術文件只是文件紀錄的一種。任何時刻，你覺得有必要寫下來的事情，或是私下針對專案的討論內容，你都可以想想是不是能將內容公開。
+
+試著盡量讓你的專案規劃保持透明公開：你們期待什麼類型的貢獻者，如何審查貢獻，或者你們做某些決定時的理由。
+
+如果你注意到有很多使用者遇過同樣的問題，那麼你應該將回覆記錄在 README 中。
+
+如果是會議的內容，試著將你的筆記或重點摘要附在相關的 issue 裡頭，這樣的公開方式有時會給你意想不到的回饋。
+
+記錄一切也適用於你的工作。如果你正在進行重要的更新工作，請將它放入 pull request 並標記為正在進行中（WIP）。讓其他人了解，能夠在該工作的初期有參與感。
+
+### 積極迴應
+
+一旦你[推廣專案](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-03.md)，人們將會給你們回饋。他們可能會問專案是如何工作的，或者希望有人教他怎麼使用。
+
+當有人提出一條 issue ，提交一個 pull request ，或詢問專案有關的問題時，你們應該盡快回覆他們。當你們快速地做出反應時，大家會覺得有參與到對話，會有熱情去參與專案。
+
+如果你無法做到及時，至少試著去及早確認，如此一來有助於提高大眾的參與度。以下是@tdreyno在[Middleman](https://github.com/middleman/middleman/pull/1466)回覆的一個pull request：
+
+
+
+[一項 Mozilla 的研究](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 發現如果貢獻者在48小時內收到代碼審查，他們會有很高的回頭率，且極有可能會再次貢獻。
+
+與專案有關的討論也可能發生在網路的其它地方，例如 Stack Overflow ， Twitter ，或者 Reddit 。你可以在這些網站設定通知，當有人提到你的專案時，可即時的收到提醒。
+
+### 為你們社群提供一個聚會的場所
+
+有兩個理由可以解釋為什麼要給社群提供聚會的場所。
+
+第一個理由是為了貢獻者。讓社群的人相互認識。因為有共同興趣的人一定會想要一個可以聊天的地方。當資訊是公開的而且容易接觸時候，任何人可以透過過去的資料，快速的跟上大家的話題。
+
+第二個理由是為了你自己。如果沒有提供公共場所來談論專案，大家可能會直接與你聯繫。剛開始可能覺得回覆私訊很輕鬆。但是一段時間後，尤其是如果專案變的熱門時，就會感到疲於應付。不要私下和人們討論你們的專案，直接請他們去指定的公共渠道。
+
+公共交流和指引人開一條 issue 一樣簡單，而不是直接發電子郵件或者在你的部落格上留言。為了方便人們談論專案，你可以設置一個郵件列表、創一個 Twitter 賬號， Slack ， IRC 頻道。或者嘗試以上所有的方式。
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) 每隔一週抽出辦公時間來協助社群成員：
+
+> Kops 每隔一週都會提供晤談時間，為社群提供幫助和指導。 Kops 維護者約定好留出一些時間專門與新手一起工作，處理 PR，以及討論新的功能。
+
+此外請謹記，有一些事情反而是不適合公開討論的：1）有關資安方面的 issues 2）嚴重違規準則的行為。你應該為大家提供一個私下討論這些 issue 的方式。若不想用自己的個人信箱，那麼就設一個專用的郵箱
+
+## 讓社群成長茁壯
+
+社群擁有強大的能量。這種能量可能是正面的也可能是負面的，一切都取決於你如何駕馭它。隨著社群的成長，要想辦法讓之成為建設性的力量，而非具有破壞性的。
+
+### 不要容忍來者不善的人
+
+熱門的專案都不可避免地會吸引到想破壞社群的人。他們可能會從一些不必要的爭論開始，對一些細枝末節糾纏不清，或用語言傷害他人。
+
+對於這些人，必須採取零容忍的政策。一旦猶豫不決，那麼這些負面的人會給社群的其他人帶來不愉快的感覺。甚至出現劣幣驅逐良幣的現象。
+
+
+
+對專案的顯而易見的問題進行定期辯論，會分散別人的注意力，包括你自己，新人如果看見這樣的情景，他們可能不會加入到專案中來。記得要將精力放在重要的任務上。
+
+當發現社群中有負面的行為時，要即時、公開的指出來。要用堅定的語氣解釋他們的行為為什麼是不可接受的。如果問題持續發生，你有必要 [請他們離開](../code-of-conduct/#蒐集有關違規的資訊) 。你的 [行為準則](../code-of-conduct/) 是為這些情境準備的建設性指南。
+
+### 知道貢獻者在哪裡
+
+隨著專案的成長，好的說明文件會變得愈加重要。不固定的貢獻者或路人不可能一下子就對專案非常熟悉，一份好的文件，能讓他們很快地找到他們需要的資訊。
+
+在 CONTRIBUTING 文件裡，需要明確告訴新來的貢獻者該如何使用。為了想要達到這個目的，你也許會想要設立一個專區說明。
+
+
+
+試著對每個 issue 標上標籤，為不同類型的貢獻者做指引：例如，[_"僅供入門者"_](https://kentcdodds.com/blog/first-timers-only), _"適合新手的Bug"_, 或者 _"說明文件"_. [這些標籤](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14)能夠幫助新人快速瀏覽 issues 並且著手開始。
+
+最後，試著撰寫易讀的說明文件讓人們在每一步的過程中都很流暢。
+
+你不可能與專案中大多數的人互動，因為有些人怕犯錯，或不知道該從何處開始，結果就可能讓你錯失獲得貢獻的機會。但有時候也只是幾個字，就能避免一些人沮喪地離開你們的專案。
+
+例如[Rubinius](https://github.com/rubinius/rubinius/)在[它的貢獻指南](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md)開頭寫道：
+
+> 我們感謝你們使用 Rubinius 。這專案是個充滿愛的工作，我們感激所有參與的人，不論是為我們抓 bug 、提升性能或完善說明文件。每一個貢獻都是有意義的，感謝你們的參與。話雖如此，我們還是要求參與者遵守一些指南，如此一來我們也才能夠回覆你們的 issue 。
+
+### 分享專案的所有權
+
+
+
+當大家覺得自己也是專案的主人之一時，就會非常樂意為專案付出。這並不代表就要去調整專案的願景，又或者代表要接受你不要的貢獻。但是社群越信任他們，他們就會越樂意待在這。
+
+試著找一些方法向社群分享你的所有權，這裡有一些經驗和大家分享：
+
+* **不要親自去修簡單（不嚴重）的錯誤。** 相反，將這些錯誤作為招募新貢獻者的工具，或指導有意貢獻付出的人。剛開始可能會覺得過程很不自然，但一段時間你會得到想要的結果。例如，在[Cookiecutter](https://github.com/audreyr/cookiecutter) 的一則 issue 下面， @michaeljoseph 要求貢獻者提交一個 pull request ，而不是親自處理它。
+
+
+
+* **在專案中添加一個貢獻者列表或者作者列表** 記錄每一個參與貢獻的人。
+
+* 如果社群有了一定的規模，就 **發送一封信或者發表一篇文章** 感謝貢獻者們。[Rust 週報](https://this-week-in-rust.org/)和 Hoodie 的[Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)就是兩個非常好的範例。
+
+* **給每個貢獻者提交的權限。**@發現這樣會使大家[越來越樂意發表他們的補丁](https://felixge.de/2013/03/11/the-pull-request-hack.html)，甚至找到人手來協助維護他已很久沒處理的專案。
+
+* 如果專案是放在 GitHub 上，那麼 **將專案從你們的個人賬號轉移到一個[組織](https://help.github.com/articles/collaborating-with-groups-in-organizations/)**，加入至少一個備份管理員。組織能讓社群與來自外界的貢獻，彼此協作的工作變得更加容易。
+
+事實上很多專案[只有一個或者兩個維護者](https://peerj.com/preprints/1233.pdf)去做大部分的工作。隨著社群變得越來越大，就會有更多的人參與進來。
+
+雖然並不是一直都有人在回答問題，但是你可以去試著增加一些機會，讓他人有能夠參與的機會，越是儘早開始，越是能夠獲得幫助。
+
+
+
+## 化解衝突
+
+在專案的一開始，做決定是蠻容易的事。想做什麼就放手去做吧。
+
+隨著專案變得熱門，會有更多人對社群的決策感興趣。如果專案有很多使用者，你會發現大家都很關心決策，或者踴躍的提交他們的 issue ，即使社群沒有很多貢獻者。
+
+大多數情況下，如果你們經營了一個友善、受尊重的社群並紀錄社群歷程公開給大家知道，社群應該能自己找到解決方案。但有時也會遇到難以處理的麻煩。
+
+### 建立友好的氛圍
+
+當社群正熱烈討論一個困難的 issue 時，火氣可能會不小。人們可能會為此憤怒或者沮喪，甚至會做出直接的人身攻擊。
+
+身為一名維護者的工作就是別讓這種情況惡化。即使你對該話題有自己強烈的看法，也要盡量擔任一個仲裁者或推動者的角色，而非跳下去參與爭論以及推動自己的觀點。如果有人態度不好或者嘗試壟斷話題，那麼請[立即採取行動](https://ocselected.github.io/open-source-guide/building-community/)，讓討論保持它應有的禮節，讓討論是有意義的。
+
+
+
+一些人希望得到指導。試著當一個好典範。當然你仍然可以表達失望、不高興或者憂慮，但得心平氣和。
+
+保持不慍不火並不容易，但是展現領導力能促進社群健康的發展。網路世界感謝你們的付出。
+
+### 視 README 為最高原則
+
+README [不僅僅是指導手冊](../starting-a-project/#編寫自述文件)。它也是一個談論目標、願景和路線的地方。
+如果人們放太多精力在討論特定功能的優點，這時重新審視 README 並討論遠景也許會比較有幫助。關注 README 也能讓大家就事論事的去討論，讓對話變得有建設性的。
+
+### 專注過程，而不是結果
+
+一些專案用投票的方式做重要決定。雖然乍看之下覺得這樣是合理的作法，但投票強調的是得到一個「答案」，而不是傾聽以及理解每個人的顧慮。
+
+投票會變成政治，不論是在往後互助的過程中，或是投票時，社群成員都會備感壓力。而且不是每個人會參與投票，可能你們的社群[保持沉默的人佔多數](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users)，或甚至使用者根本不知道投票這件事正在發生。
+
+有時投票是必要的手段。盡你們所能的強調[「尋求共識」](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)而不是要獲得共識本身。
+
+尋求共識的過程中，社群成員討論關心在乎的事，直到他們覺得意見已經獲得充分的表達。當僅剩下一些次要的議題時，社群就往前邁進。「尋求共識」不能確保社群能得到一個完美的解答。而是側重聆聽和討論。
+
+
+
+即使不全然採用尋求共識的方式，身為一名維護者，讓人們知道你願意傾聽意見是一件很重要的事。讓其他人知道意見有被聽見，並且承諾解決他們的問題，這很大程度上減少了棘手情況的發生。接著言出必行的去採取行動。
+
+不要為了得到解決方案而急於做出決定。在有所行動前請確保每個人已經知情，保持所有的資訊公開。
+
+### 將對話重點聚焦於行動
+
+討論很重要，但是有成效和沒有效果的對話是有很大區別的。
+
+鼓勵討論，只要它正積極地朝著解決問題的方向前進。如果你很清楚地發現對話已經漸漸停滯下來、偏離主題、溝通開始對人對不對事或在小細節上鑽牛角尖，那就是時候該結束對話了。
+
+允許上述的這些對話進行下去，不僅無法解決問題，還不利於社群的健康發展。這樣讓大家認為這類的對話是被允許甚至是被鼓勵的，它可能阻礙了人們往後提問的意願或者在解決之後的問題上產生困擾。
+
+當你或其他人每次提出想法時，問問自己：「這發言如何使我們更接近一個解決辦法？」
+
+如果對話開始有發散的徵兆，問問團隊：「我們下一步該做什麼？」才能重新聚焦討論。
+
+如果一個對話沒有清楚的方向，也會沒有明確的辦法可以執行，又或者合適的解決辦法已經被採納，那麼就結束 issue 並解釋為什麼結束它。
+
+
+
+### 謹言慎行
+
+了解來龍去脈很重要。想想誰正在參與討論，以及這些人如何代表社群的其他人。
+
+社群的每個人都是否參與討論？大家是否對這個議題感到困擾？還是有人在搗亂？記得不僅要關心有發言的人，也要記得為社群中保持沉默的人考量。
+
+如果這個議題不代表社群普遍的需求，你們可能要理解這只是少數人的疑慮。如果這是一個反覆出現的 issue ，而且直到現在還是沒有一個明確的解決辦法，那麼指引他們去看看以前討論的內容，並結束這個討論串。
+
+### 找出社群中的決策者
+
+保持態度良善，維持目標清晰的對話，很多困難都可以被解決。但即便在富有建設性的對話中，還是可能會對該如何執行有不同的意見。在這樣的情況下，你要找找看是否有一個人或一組人，可以擔任決策者。
+
+負責做出決策的人可能是專案的主要維護者，或者是大家投票選出的一個團體。理想情況下，事前要先確定決策者是誰和與之相關的事宜，寫在 GOVERNANCE 文件以便不時之需。
+
+使用決策者應該是你們最後的手段。區分這些 issues 是一個社群成長和學習的機會。利用這些機會協作，儘量找出問題的解決辦法。
+
+## 社群是開源的❤️
+
+健康，蓬勃的社群每週都會為開源注入大量的動力。許多貢獻者指出，開源專案的其他成員是促成他們參與（或導致不參與）的主要因素。通過學習如何建設性地利用這股力量，你會在協助的過程中讓他人有個難忘的開源體驗。
diff --git a/_articles/zh-tw/code-of-conduct.md b/_articles/zh-tw/code-of-conduct.md
new file mode 100644
index 00000000000..5b312f29728
--- /dev/null
+++ b/_articles/zh-tw/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: zh-tw
+title: 建立一套行為準則
+description: 為了促進社羣朝健康且有建設性的方向發展，必須設立一個共同遵守的行為守則。
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## 我爲什麼需要行爲守則
+
+行爲守則是一份確立專案參與者行爲規範的文件。採用和執行行爲守則可以幫助你們的社群營造積極的氛圍。
+
+行爲守則不僅幫助保護你們的參與者，同時還有你們自己。如果你們維護一個專案，隨着時間的推移，可能會發現其他參與者懶散的態度會讓你們疲憊或對工作不滿意。
+
+一份行爲守則可以幫助你們促進健康，有建設性的社群行爲。積極主動減少你們或其他人在你們的專案中變得疲勞的可能性，並幫助你們在有人做出你們不同意的事情時採取行動。
+
+## 建立行爲守則
+
+儘可能早地建立行爲守則，當你們第一次創建專案的時候。
+
+此外，說出你們的要求。行爲守則的描述遵循如下幾點：
+
+* 行爲守則在哪裏有效 _(只在issues以及pull requests，或者社群活動？)_
+* 行爲守則適用於誰 _(社群成員以及維護者，那贊助商呢？)_
+* 如果有人違反了行爲守則會怎樣？
+* 大家如何舉報違規
+
+無論你們在哪裏，請使用已有的行爲守則。[貢獻者盟約](http://contributor-covenant.org/)是一個被超過40，000個開源專案（包括Kubernetes, Rails和Swift）所使用的行爲守則。
+
+[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](http://citizencodeofconduct.org/)都是非常好的行爲守則。
+
+請將CODE_OF_CONDUCT文件放在你們專案的根目錄，並在README中附上其鏈接，這樣對你們的社群是可見的。
+
+## 決定你們如何執行行爲守則
+
+
+
+你們應該解釋如何執行行爲守則在違規發生**之前**。有幾點理由說明爲什麼這麼做：
+
+* 必要的時候，它表示你們處事認真謹慎。
+
+* 你們的社群會因爲投訴確實可以得到回覆而更加放心。
+
+* 如果他們發現自己因爲違規而被調查時，你們能確保社群的審查流程是公平透明的。
+
+你們可以給大家一個私有的渠道（如email地址）以便大家報告違規行爲以及解釋誰收到了這一的報告。它可以是維護者，一組維護者或行爲守則工作組。
+
+請不要忘記了有人可能想要報告某些人違規接受了這些報告。在這樣的情況下，也給他們舉報那些人的機會。例如，@ctb和@mr-c [在他們的專案上解釋](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst)， [khmer](https://github.com/dib-lab/khmer)：
+
+> 對於濫用現象，擾亂或者其他不可接受的行爲都可以向**khmer-project@idyll.org**（僅由C. Titus Brown和Michael R. Crusoe處理）發送郵件。要報告涉及其中任何一個的問題，請電郵**Judi Brown Clarke，Ph.D.** BEACON行動進化研究中心的多元化主任，NSF科學技術中心。
+
+爲了獲得靈感，可以查閱Django的[執行手冊](https://www.djangoproject.com/conduct/enforcement-manual/)（你們是否需要如此詳細的手冊，這取決於你們的專案）。
+
+## 執行你們的行爲守則
+
+有時，儘管你們盡了最大的努力，仍然會有人違反守則。當這樣的情況發生時，有幾種方法來解決消極或有害的行爲。
+
+### 蒐集有關違規的資訊
+
+認真對待社群中每個成員的想法。如果你們收到有人違規的報告，請認真對待並調查此事，即使它不符合你們自己的經驗。這樣做可以向你們的社群表面，你們珍視他們的觀點和信任他們的判斷。
+
+有的社群成員可能是讓大家一直不舒服的慣犯，或者他們只是說了或做了一次。這都需要依據實際情況進行處理。
+
+在你們做出迴應之前，請認真思考發生了什麼事。通過閱讀他們過去的評論和對話可以更好地理解他們爲什麼要那樣做。儘量收集其他人對他們行爲的看法。
+
+
+
+### 採取適當的行動
+
+當蒐集和處理足夠的資訊後，你們需要決定做什麼。當你們在考慮下一步的時候，請牢記你們的目的是營造一個安全，尊重和協作的社群氛圍。不僅要考慮如何處理有問題的情況，還要考慮們的反應將如何影響你們社群的其他行爲和期望。
+
+當有人報告違規時，處理它是你們的工作，而不是他們的。有時，報告者透露他們的資訊會給他們的職業生涯，聲譽和人生安全帶來很大的風險。迫使報告者面對騷擾者會將他們置於妥協的位置。除非報告者有特別的要求，你們應該直接和有問題的人溝通。
+
+這裏有些方法幫助你們迴應違規行爲：
+
+* **向相關人員發出公開警告**以及解釋他們的行爲產生了怎樣的負面影響，最好在發生問題的地方。在可能的情況下，公開溝通會向社群的其他人傳達你們認真對待行爲守則。要友善，但堅定的溝通。
+
+* **私下接觸相關人員**向他們解釋他們的行爲對其他人產生了怎樣的負面影響。如果相關情況涉及到個人敏感資訊，你們可能會使用私有通信方式。如果你們和一些人私下溝通，對於首先報告這個情況的CC來說是個好主意，因爲他們知道你們採取了行動。在徵求他們的意見之前，請向報告人徵求同意。
+
+有時，一個解決方案不能達到目的。有關的人可能在面對或者不改變他們的行爲時變得氣勢洶洶或敵對。在這種情況下，你會想到考慮採用強制措施。例如：
+
+* **暫停有關人員**在專案中的工作，通過暫時禁止參與專案的任何方面執行
+
+* **永久禁止**有關人員加入專案
+
+對于禁止成員的做法，你們應該非常謹慎，只有在沒有其他解決方案的情況下才能使用。
+
+## 維護者的責任和義務
+
+行爲守則不是可以任意執行的法律。你們是行爲守則的執行者，同時你們的責任是遵守行爲守則確立的規矩。
+
+作爲維護者，你們可以爲社群指定準則，同時你們可以根據行爲守則執行這些準則。這意味着你們需要認真處理違規行爲。報告者對他們的投訴進行了徹底和認真地審查。如果你們確定他們報告的行爲沒有違規，你們需要他們進行溝通並解釋你們爲什麼不進行處理。他們會怎樣做，取決於他們：容忍他們認爲有問題的行爲，或者停止參與社群。
+
+如果報告的行爲沒有_技術上_的違規，這可能表面你們的社群依然存在問題，同時你們應該調查潛在的問題以及採取相應的行動。這可能包括修改你們的行爲守則，以澄清可接受的行爲和/或與行爲被舉報的人交談，並告訴他們，雖然他們沒有違反行爲守則，但是他們在期望和確定的邊緣另其他參與者感到不舒服。
+
+最後，作爲維護者，你們給可接受的行爲建立和執行標準。你們有能力塑造專案社群的價值觀，以及參與者希望你們能 公平公正地執行這些價值觀。
+
+## 鼓勵你們希望看見的行爲 🌎
+
+當你們的社群變得似乎敵對或者不受歡迎時，即使是一個大家能容忍的個人行爲，也會讓你們失去很多貢獻者，你們可能再也遇不到其中的一些人。雖然執行或者採用行爲守則很難，但是營造一個受歡迎的環境將幫助你們社群成長。
diff --git a/_articles/zh-tw/finding-users.md b/_articles/zh-tw/finding-users.md
new file mode 100644
index 00000000000..cb109a3b806
--- /dev/null
+++ b/_articles/zh-tw/finding-users.md
@@ -0,0 +1,156 @@
+---
+lang: zh-tw
+title: 找尋專案的使用者
+description: 透過使用者的心得來幫助你的開源專案成長。
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+ - beginners
+ - building
+---
+
+## 四處傳播
+
+沒有規定說應該怎麼去倡導剛創建的開源專案。但沒有任何理由說必須默默無聞的在開源專案上工作。相反，如果你向有更多的人發現和使用你的開源專案，你就應該讓所有人知道你所努力的成果！
+
+## 發出自己的聲音
+
+在你開始推廣你的專案之前，你應該能夠解釋你的專案是做什麼的，爲什麼大家需要他?
+
+是什麼讓你的專案變得不同或者有趣，在自己心中問這些問題會讓你更容易說服別人。
+
+牢記一件事情，別人之所以使用你的專案，甚至是爲你的專案做貢獻，是因爲你的專案解決了他們的問題。所以你要找出他們需要什麼，然後把他當成你專案的賣點或者說價值所在。
+
+舉個例子，[@robb](https://github.com/robb)用代碼實例來清晰的闡述爲什麼他的專案[Cartography](https://github.com/robb/Cartography)是有用的。
+
+
+
+如果你想深入瞭解如何挖掘專案的"賣點"，看一下Mozilla的["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/)，練習如何建立用戶的形象。
+
+## 幫助人們找到並關注你的專案
+
+
+
+通過引導他們到一個唯一的地址來幫助人們發現和記住你的專案。
+
+**要有一個推廣的主陣地。**一個Twitter賬號，Github鏈接，或者IRC頻道是引導人們查看你們專案的一個簡單的方式。這些方式也給你日益增長的社群一個討論的好地方。
+
+如果你目前還不想給你的專案搞這麼多亂七八糟的東西，而且還要在有機會的時候推廣你的Twitter帳號和Github帳號。舉個例子，如果你某一個討論會或者活動上發言要保證在你的簡歷或者幻燈片上包含這些資訊。只有這樣人們才會知道怎麼找到你或者關注你的工作。
+
+
+
+**考慮給你的專案做一個網站**一個網站可以讓你的專案更加友好，而且更加容易瀏覽，更重要的是附上清晰的文檔和教程。這也是象徵著你的專案還是活躍的，這會讓你的用戶使用你專案的時候感覺更放心。可以用一些例子告訴人們如何使用的專案。
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django的協作者說，我們給Django做的網站可以說是"在早期開發Django的時候做的最好的一件事情了"。
+
+如果你的專案是託管在GitHub上的，你可以用[GitHub Pages](https://pages.github.com/)簡單的創建一個網站。[Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) 是一些優秀的內容詳盡的網站的[例子](https://github.com/showcases/github-pages-examples)
+
+
+
+現在你的專案有了"賣點"，和讓人們很容易發現你專案的渠道，接下來我們談談如何和你的用戶交流吧！
+
+## 到你專案的受眾在的地方去（線上）
+
+網上拓展是分享和快速宣傳專案的一個好方法。藉助一些網上的渠道，你有可能找到一大批受眾。
+
+利用既有的線上社群和平臺去找你的受眾。如果你的開源專案是一個軟件專案，你可能會在[Stack Overflow](http://stackoverflow.com/), [reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), 或者[Quora](https://www.quora.com/)。找到你覺得人們會最有可能從你的專案中受益或者對你專案感興趣的渠道。
+
+
+
+來看看下面的一些方法吧，也許推廣你的專案的時候用得著。
+
+* **快找找有沒有相關的開源專案和社群。**有時候，你不需要直接的推廣你的專案。如果你的專案對使用Python的數據科學家來說是無可挑剔的，那麼就去找Python數據科學的社群。等他們知道你的專案之後，很自然的就會談論然後分享你的工作成果。
+* **如果你專案嘗試解決某些問題，那麼找到會遇到這些問題的人。**想象你的專案受眾會在哪些論壇，然後搜索這些論壇，回答他們的問題，然後找一個合適的實際，向他們建議使用你的專案來作爲一種解決方案。
+* **尋求反饋。**給一個可能會用到你專案的人介紹你自己和你做的工作。對哪些人會從你的專案受益要很明確。嘗試完善一下下面這句話："我覺得我的專案能夠幫助A，那些嘗試做B的人"。聽取和回覆別人的反饋，而不是簡單的推廣。
+
+一般來說，在你索取什麼回報之前先把精力放在幫助別人上。因爲在網上推廣一個專案對任何人都是一個不難的事情，所以有很多人和坐著一樣的事。告訴人們你是誰，而不是你想要什麼，這樣才能從眾多推廣者中脫穎而出。
+
+如果沒有人對你的推廣感興趣，不要灰心！大部分的專案的開展都是一個要花費數月和數年的反覆過程。如果你第一次沒收到反應，嘗試換一種策略，或者找辦法給別人的專案做做貢獻。這都是些需要時間和奉獻精神的事情。
+
+## 到你專案受眾在的地方去（線下）
+
+
+
+線下活動是一個推廣專案流行的方式。這是一個接觸某個忠實聽眾和建立深層次的聯繫的好方式，特別是如果你對到場的開發者感興趣的話。
+
+如果你還是個[公中演講的新手](http://speaking.io/)，從尋找一個和你專案使用的語言或者生態系統相關的當地的聚會開始吧。
+
+
+
+如果你從來沒在公共場合講過話，感覺緊張那就太正常啦！記住你的聽眾就在哪兒，因爲他們都是真正的想聽你介紹你的專案。
+
+當你在寫你的演講稿的時候，把重點放在你的聽眾會感興趣而且能獲取價值的事情上。保證你的語言要友好和和藹可親。笑一笑，深呼吸，幽默一點兒。
+
+
+
+等你準備好了，考慮一下在某個會議上發言的時候推廣你的專案研討會可以幫助你接觸更多人，有時候是來自全世界各地的人。
+
+
+
+## 贏得口碑
+
+除了上面提到的策略之外，邀請人們分享和支持你的專案的最好辦法就是分享和支持他們的專案。
+
+幫助新手，分享資源，給別人的專案認真的做貢獻會幫助你建立起良好的聲譽。然後他們就很有可能知道你的專案而且更有可能關注和分享你在做的事情。
+
+有時候，這些關係還會進一步發展成更廣闊的生態系統中的官方合作伙伴（意思即使你有可能成爲那些有名社群的成員）
+
+
+
+種一棵樹最好的時候是十年前，其次是現在。所以何時開始建立你的聲望都不晚。即使是你早就已經建立了自己的專案，還是要繼續找辦法幫助別人。
+
+建立用戶群沒有一蹴而就的方法。獲取別人的新人和尊重需要時間，同樣，建立聲望的過程也永遠不會停止。
+
+
+
+## 保持精進
+
+有時候，讓人麼注意你的開源專案會花費很多時間。但是沒關係！現在很多流行的專案也都是花了很多年才有今天的活躍度。把重點放在建立聲望上而不是企圖一夜成名。耐心一點，一如既往的和那些可能會從中受益的人們分享你的專案。
diff --git a/_articles/zh-tw/getting-paid.md b/_articles/zh-tw/getting-paid.md
new file mode 100644
index 00000000000..45d604e305c
--- /dev/null
+++ b/_articles/zh-tw/getting-paid.md
@@ -0,0 +1,163 @@
+---
+lang: zh-tw
+title: 透過為開源專案工作而獲得報酬
+description: 透過經濟上的補助，支持你在開源專案裡的工作。
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+ - best-practices
+ - leadership
+---
+
+## **為何有人尋求經濟上的支持**
+
+很多開源工作都來自志願者的辛勤付出。例如，有人在使用的過程中遇到了臭蟲，就自己著手修正；也有些人單純利用自己的閒暇時間享受維護開源專案所帶來的樂趣。
+
+
+
+有些人為開源貢獻，卻不求報酬，可能的原因有：
+
+* **他們本來就有一份自己熱愛的全職工作**，這可以讓他們在沒有後顧之憂的情況下利用業餘空閒時間來爲開源做貢獻。
+* **他們熱衷於沉浸在開源的思考中**，或是純粹享受創作的過程，不想因為有收錢而有要負責的壓力。
+* **他們能夠從開源的貢獻中獲得其它好處**，比如獲得名聲、當作自己的作品集或是藉此學習新的技能，又或者是能跟社群互動。
+
+
+
+但是對其他人來說，尤其是正在進行的或者是需要花費大量時間的付出時，能夠取得報酬是人們積極參與開源的唯一理由，無論是專案的需要還是個人原因。
+
+維護熱門的專案是一項很重要的責任，每週需要花上 10～20 小時，而不是每個月花上幾個小時就能搞定。
+
+
+
+有償工作也能使各行各業的人創造有意義的貢獻。有些人需要贊助才願意參與開源專案，可能是因為他當前的財務收入不足、身上有債務、或者需要照顧家庭、撫養他人。有能力但在經濟上沒辦法無償貢獻自己時間的人，依然能當個貢獻者。這涉及道德倫理，正如 @ashedryden 在 [無償勞動的倫理和開源軟體社群](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) 一文中所描述的，人們經常誤以為，專案成果都是由那些在事業上已經有成就的人們完成的，這些人得以透過無償貢獻獲得更多的成果，而其他無法負擔無償貢獻的人就會錯失了這樣的機會，不斷負向循環下去，會使得開源社群越來越缺乏多樣性。
+
+
+
+如果正在尋找經濟上的支持，有兩個方法可以參考。透過群眾募資，或是找一能夠爲專案提供資金的組織。
+
+## **為你的貢獻募資**
+
+在今日，無論是兼職或全職，很多人透過開源獲得了報酬。最爲常見的做法就是去找願意爲你付出的時間和工作成果掏腰包的雇主談談。
+
+如果你的老闆使用了該開源專案，贊助的事情自然就比較好談，盡量發揮創意地去向雇主提案。也可能雇主沒有使用到開源專案，但他們有使用 Python ，用來經營一個熱門的專案，吸引有興趣的 Python 開發者，又或者都不是，那老闆也至少營造了一個對開發者友善的環境。
+
+
+
+如果你現在還沒有爲開源專案做工作，但是你希望你現在所做得成績開源出來，那麼你可以和你的老闆講，奉勸他將內部的軟體開源。
+
+很多公司都在開發開源專案，從而能夠打造自己的品牌，以及希望僱傭到高質量的人才。
+
+@hueniverse ，舉例來說，有充足的證據證明 [沃爾瑪對開源的投資](https://hueniverse.com/2014/08/15/open-source-aint-charity/)是合理的。 @jamesgpearce 同樣，Facebook的開源專案讓它的招聘顯得[與衆不同](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) :
+
+> 開源能夠與我們Hacker文化密切配合，也能夠和我們的組織融洽。我們詢問員工："在Facebook真的那麼的在意開源軟體？" 超過2/3的人的回答是"yes"。一半的人表示，該計劃對他們爲我們工作的決定作出了積極的貢獻。這可不是一個戲謔的數字，我們希望繼續保持這樣。
+
+如果你所在的公司不贊同這麼做，沒關係，重要的是保持社群和企業活動之間的界限清晰。你要告訴老闆，開源的維持是由全球各地的人所貢獻，要比任何一個公司或某一地域都大的多。老闆會自己作出權衡的。
+
+
+
+如果你實在無法在當前的僱主下開展相關開源的工作，那麼是該考慮換老闆的時候，應到找個支持想開源作貢獻的老闆！尋找那些致力於開源工作的公司。比如：
+
+* [Ghost](https://ghost.org/) 就是一家圍繞很多[開源專案](https://github.com/tryghost/ghost)的好公司
+* [Rackspace](https://www.rackspace.com/en-us) 甚至爲其員工提供了[貢獻開源守則](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/)
+
+那些大公司發起的專案，如 [Go](https://github.com/golang) 或 [React](https://github.com/facebook/react)，均希望僱傭到優秀的工程師來爲他們工作。
+
+當然最終還是要看你自身的條件而定，你甚至可以利用你的開源專案來獨立的進行融資。這邊就有幾個案例：
+
+* @gaearon 通過 [Patreon crowdfunding campaign](http://redux.js.org/)爲他的專案 [Redux](https://github.com/reactjs/redux)成功的融到了資金。
+* @andrewgodwin [通過 Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 爲Django schema 遷移拿到了資金
+
+## 為你的專案尋找資助
+
+除了針對個人貢獻者的建議之外，還有一些專案可以從公司、獨立投資方、以及其它的資金處來獲得進一步的工作。
+
+機構資金可能用於支付當前的貢獻者，涵蓋運行專案的成本（如託管費用）或投資於新功能或想法。
+
+一些獲得組織資助的專案案例：
+
+* **[webpack](https://github.com/webpack),** [通過 OpenCollective](https://opencollective.com/webpack) 從公司和個人來籌集資金
+* **[Vue](https://github.com/vuejs/vue),** 由 @yyx990803 創建，[通過 Patreon](https://github.com/open-source/stories/yyx990803)獲得資助
+* **[Ruby Together](https://rubytogether.org/),** 由 @indirect 創建的非盈利組織 ，爲諸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基礎設施專案提供資金支持
+
+儘管開源日漸的流行，但是爲專案尋找資金仍然是處於試驗中。目前所收集到的包括：
+
+* **通過大力宣傳活動或募捐，爲您的工作籌集資金** 這策略在你擁有足夠的粉絲，或者是已經社群聲譽良好的情況下，又或者是專案非常的受歡迎，等情況下有效。
+* **接受基金巨頭的資助** 一些軟體基金會和公司爲開源的相關工作提供很好的機會，如[Python 軟體基金會](https://www.python.org/psf/grants/), [Mozilla 基金會](https://www.mozilla.org/en-US/grants/)、以及[Stripe](https://stripe.com/blog/open-source-retreat-2016).
+* **獲得公司或獨立投資商的贊助** 通過軟體基金會，或者是乾脆 **創業** 來支撐專案。
+
+更多的案例和細節， @nayafia [專門寫過一個指南](https://github.com/nayafia/lemonade-stand) ，專門針對的就是如何爲開源工作獲得報酬。不同類型的資助需要不同的技能，所以仔細的掂量下資格，然後找個最適合自己的方式。
+
+## 建立經濟上的支持
+
+無論你的專案是新的創意，還是已經運行多年，你都需要爲你的資助者滿意，並提出有效而合理的案例。
+
+不管是你自己尋找相應的工作，還是爲專案融資，你都應該嘗試回答下面的問題。
+
+### 影響
+
+爲什麼說這個專案有實際用處？你的用戶或潛在的用戶會喜歡它？5年之後它會是什麼樣子？
+
+### 牽引
+
+嘗試着去收集一些和你專案休慼相關的證據，比如指標、有趣的事情、還是其他人的推薦。是否有其它公司或者是業內意見領袖正在使用你的專案？如果沒有的話，是不是應該去找相應的人去推薦下？
+
+### 充分利用資助者的價值
+
+資助者，無論他是僱傭你的老闆，還是一家獲得授權的基金會，你都有機會和他們頻繁的進行接觸。 他們爲什麼會放棄其它機會而去支持你的專案？他們個人有何好處？
+
+### 利用風險投資
+
+您將如何用擬議的資金完成什麼？專注於專案里程碑或成果，而不是支付工資。
+
+### 你將以何種方式接受資助
+
+資助者是否有關於宣傳的額外需求？例如，你可能需要您可能需要成爲非盈利組織或擁有非營利性財政贊助商。又或者是資助者必須給到個人而不是一個組織。這些不同的需求會因爲不同的資助者而異，所以請事先做好準備。
+
+
+
+## 嘗試，不要放棄
+
+賺更多的錢不是件容易的事情，無論你是在開源專案，亦或是在非盈利組織，又或者是軟體的創業公司，但是無論在哪裏，掙得更多錢的祕密就是更多的創造力。當確定了你想如何獲得報酬的時候，請繼續你的研究，將自己放在投資人的角度來看問題，可以幫助你更好的構建一個更加令人信服的賺錢之道。
diff --git a/_articles/zh-tw/how-to-contribute.md b/_articles/zh-tw/how-to-contribute.md
new file mode 100644
index 00000000000..aba56af0429
--- /dev/null
+++ b/_articles/zh-tw/how-to-contribute.md
@@ -0,0 +1,520 @@
+---
+lang: zh-tw
+title: 如何為開源做貢獻？
+description: 想為開源貢獻心力？一個菜鳥老手都值得一看的指南。
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+ - beginners
+ - building
+---
+
+## **為何要為開源貢獻心力？**
+
+
+
+透過為開源貢獻力量，能從中學習、幫助他人並且從中累積相關技能的經驗 - 任何你能想像得到的技能。
+
+為什麼會有人為開源做出貢獻？有數不清的原因！
+
+### **鞏固現有技能**
+
+無論是撰寫程式碼、設計使用者介面、平面設計，撰寫文章或是組織活動，只要你有意願實踐，你總能在開源專案中找到自己的位置。
+
+### **認識那些與你有相似興趣的人**
+
+一個友善、溫暖的開源社群會讓人們持續的參與。許多人透過參與開源建立了深厚的友誼，可能是在一次的技術研討中，也可能是在線上聊天室的閒聊中發生。
+
+### **尋找導師，並且嘗試幫助他人**
+
+與他人在共享的專案中工作，你會需要向他人解釋自己是如何做的，同時也需要向他人求助。每個參與開源的人都教學相長。
+
+### **在公眾建立你的名聲（以及職業名聲）**
+
+根據開源的定義，你在開源裡的所有工作都是公開的，這也意味開源專案是一個能好好展現你實力的地方。
+
+### **學習人際交往的能力**
+
+開源為練習領導及管理的能力提供了很好的機會。例如如何解決衝突、組織團隊以及如何為工作的優先順序排列。
+
+### **鼓勵作出改變，哪怕只是很微小的改變**
+
+你不一定要持續不斷的貢獻開源才能享受參與的樂趣。你是否曾在某個網站上發現拼寫錯誤，並希望有人能夠修改它？在開源專案中你可以親自修正這樣的錯誤即可。開源讓人們自在的做事，而這正是這個世界應有的體驗。
+
+## 具體而言什麼是貢獻
+
+如果你是一名開源世界的新手，可能會對貢獻的流程心生畏懼。如何找到適合彼此的專案？不會寫程式又想參與怎麼辦？萬一中間出了差錯怎麼辦？
+
+不用擔心！條條大路通羅馬，有很多能參與開源專案的方式。以下是一些實用的技巧，幫你快速的獲得經驗。
+
+### **你不一定要會寫程式才能貢獻**
+
+對開源做出貢獻常見的誤解之一就是：要寫程式纔算貢獻。其實專案裡不需編碼的工作也是[經常被忽視](https://github.com/blog/2195-the-shape-of-open-source)的部分。你對專案所做的非程式類貢獻，其實是對專案來說莫大的幫助！
+
+
+
+即便你樂於寫程式，撰寫程式以外的貢獻對於專案來說也是舉足輕重的，維繫這樣的關係也能讓你獲得與專案的其他成員共事的機會。
+
+
+
+### **你是否熱衷於規劃活動？**
+
+* 為專案舉辦一個工作坊或線下聚會，[例如 @fzamperin 為 NodeSchool 所做的](https://github.com/nodeschool/organizers/issues/406)
+* 為專案舉辦一個大型會議﹝如果它有需求的話﹞
+* 幫助社群成員找到合適的會議，或是協助成員找到窗口提交演講的提案。
+
+### 你是否喜愛設計？
+
+* 重新佈置佈局以提高專案的可用性
+* 做一份使用者調查去整頓與完善專案導覽或菜單，像 [Drupal 所提出的建議](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* 整理一個風格指南，以幫助專案有一致的視覺設計方針。
+* 透過藝術創作設計T恤或畫一個新標誌，就像 [hapi.js 的貢獻者所做的](https://github.com/hapijs/contrib/issues/68)
+
+### **你是否熱愛寫作？**
+
+* 撰寫和改善專案的說明文件
+* 策劃一個資料夾來蒐集專案的實際應用案例
+* 辦一個專案的電子報，或者蒐整郵件列表的摘要
+* 寫一個專案教學，就像 [PyPA 的貢獻者做的](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* 翻譯專案的說明文件
+
+
+
+### **你喜歡組織活動嗎？**
+
+* 指認出過去討論過或重複的議題、推薦一個新的議題類別，讓事物井井有序
+* 瀏覽在開放狀態（open）的議題，並建議將已經處於開放狀態很久的議題設為已結束（closed）[就像 @nzakas 在專案 eslint 做的](https://github.com/eslint/eslint/issues/6765)
+* 鼓勵最近才剛提問的人將疑問闡釋清楚，加速討論的進展
+
+### **你喜歡寫程式？**
+
+* 嘗試解決一個開放狀態（open）的議題（issue） [就像 @dianjin 在 Leaflet 做的](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* 想想自己是否能協助開發一個新功能？
+* 將專案建置變得自動化
+* 改善工具及測試方法
+
+### **你喜歡幫助他人？**
+
+* 回答有關於專案的問題，例如在 Stack Overflow( [Postgres 的展示範例](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-to-ge) )或者 reddit 上
+* 回答處於開放狀態的議題
+* 鼓勵、協助創造友善的討論區禮儀
+
+### **你喜歡協助他人改善它的程式嗎？**
+
+* 為他人貢獻的程式碼做程式碼審查
+* 寫一個教學向大家介紹如何使用該專案
+* 當其他貢獻者的導師， [像在 Rust 專案中 @ereichert 為 @bronzdoc 做的](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### **其實不一定要是開源軟體的專案！**
+
+雖然很多人提到「開源」兩字是指「開源軟體」，其實不盡是如此，許多事物你都可以你可以開源協作，你可以開源一本書、開源食譜、開源一張你整理的清單，都可以像開源軟體一樣發展你想製作的東西。
+
+舉例來說：
+
+* @sindresorhus 蒐集了 [「驚奇」（awesome） 列表](https://github.com/sindresorhus/awesome)
+* @h5bp 維護了針對前端開發者的[面試題](https://github.com/h5bp/Front-end-Developer-Interview-Questions)
+* @stuartlynn 和 @nicole-a-tesla 蒐集了[關於海鸚的小知識](https://github.com/stuartlynn/puffin_facts)
+
+即使你是一個軟體開法者，撰寫說明文件也能幫助剛加入開源的你去更加的認識它。這通常也能讓你以一個不用接觸程式碼的方式自在的參與專案，當中協作的過程亦能建立你的信心與經驗。
+
+## **根據專案定位自我**
+
+
+
+除了錯誤檢查錯字的簡單工作之外，為開源做貢獻有時就像是走進陌生人群嘗試融入一樣。如果這群人已經討論西討論得的非常深入了，你突然加入劈頭就開始講東，肯定會讓人覺得你有點奇怪。
+
+與其盲目地在社群中拋出你自己的看法，不如先觀察一下社群的氛圍後再提出，這樣你的想法被注意到的機會才會增加。
+
+### **剖析一個開源社群**
+
+每一個開源社群都不盡相同。
+
+在某個開源專案中耕耘多年，意味著你只是對這一個開源專案很熟悉。若是轉換到不同的專案，你可能會發現社群的規範、用字遣詞與溝通方式都變得不一樣了。
+
+很多開源專案還是都遵循著組織架構的。嘗試認識不同社群角色和整體流程，能幫助你在加入一個新的專案時快速的找到你的定位。
+
+一個典型的開源專案都會有下列的這些人：
+
+* **作者:** 專案的發起者或發起的社群
+* **擁有者:** 有權限直接修改程式碼或修改文件的管理員（不一定和作者是同一人）
+* **維護者:** 貢獻者，負責專案的方向和組織的管理（他們通常也是專案的作者或擁有者。）
+* **貢獻者:** 只要是爲專案做出了貢獻的人。
+* **社群成員:** 專案的使用者，他們有時會積極的參與討論或是表達他們對專案走向的看法。
+
+一個較大的專案，可能底下還會細分子社群，或是針對不同任務組成的工作小組，比如負責打造工具的小組、引導社群力量的人、負責社群管理以及組織活動的小組等。試著找找看專案網站上「團隊介紹」的頁面，或著也能從說明成員編組的文件中找到更多這類的訊息。
+
+專案會有一系列的說明文件，這些文件通常會在根目錄上找得到清單。
+
+* **許可協議（LICENSE）:** 根據定義，每個開源專案都必須有個[開源許可協議](https://choosealicense.com)。如果專案沒有的話，那它不能算是個開源社群。
+* **README:** README 是一個引導手冊，對剛加入社群的人們表示歡迎，它通常會解釋專案有何用處，為何發起，以及如何快速入門等。
+* **貢獻（CONTRIBUTING）:** READMES 幫助人認識與使用專案，「貢獻」這個文件則是針對想對專案貢獻的人寫的指南。它會說明目前專案需要怎樣類型的貢獻者，並介紹貢獻時的流程是如何進行。並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。
+* **行爲準則（CODE_OF_CONDUCT）:** 這份文件裡頭設立了基本規範來約束參與者的行為以及提醒應有的禮儀，並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。
+* **其它文件:** 有些專案也許還有其它文件，例如教學、專案導覽，或者是管理政策，這在大型專案中常見。
+
+此外，開源專案還會利用如下列的一些工具來進行組織討論，閱讀這些檔案對於理解社群的想法、是如何工作的有非常大的作用。
+
+* **問題追蹤（Issue tracker）:** 這裡是人們討論專案相關問題的地方。
+* **請求提取（Pull requests）:** 這裡給人們檢查程式碼、以及相關問題的討論。
+* **論壇或郵件列表:** 一些專案會利用對話式的方式討論主題（例如 _"How do I..."_ 或 _"What do you think about..."_ 來替代回報 Bug 或特別的請求）。然而有一些專案討論過程都全程使用問題追蹤。
+* **即時在線聊天:** 有一些專案會使用聊天頻道（諸如 Slack 或 IRC），能夠隨意的談話、協作和快速的交換意見。
+
+## **找尋專案開始貢獻**
+
+讀到這裏，已經對開源專案如何運作有了進一步的了解，是該找一個合適的專案做貢獻的時候了！
+
+如果你從來都沒有爲開源做過貢獻的話，那麼請謹記來自美國總統約翰 F.肯尼迪的這段話：「**不問國家能爲你做什麼，要問你能爲國家做什麼。**」
+
+開源專案的每個面向與跨專案間都需要貢獻者，先不用太專牛角尖的去想你一定要先在那做貢獻，或是做得好不好。
+
+不如從你使用過的或將來會使用到的專案開始貢獻，你特別關注的專案才會是你會自願積極參與的專案。
+
+參與的過程中，如果有任何點子，覺得可以讓專案更好或更不一樣的，就依你的直覺行事。
+
+開源並不是會員專屬的俱樂部；它就是由你這樣的人所打造。「開源」只是針對這個世界的需要修復的問題的一個夢幻術語罷了。
+
+你或許在查看 README 的時候，發現了失效的超連結、或發現了錯字。又或者你在使用的過程中發現了問題、某件你真的覺得該寫進說明文件的議題，與其視而不見或請別人處理，試著自己投入看看是否有你能幫上忙的地方，這就是開源的精神！
+
+> 平均一個專案有[28% 的貢獻是隨意且偶然的](http://www.igor.pro.br/publica/papers/saner2016.pdf) ，像是寫說明文件、修正錯字、調整格式或翻譯。
+
+你也可以利用如下列的資源來找到合適的新專案：
+
+* [GitHub 探索](https://github.com/explore/)
+* [First Timers Only](http://www.firsttimersonly.com/)
+* [你的第一個 PR](https://yourfirstpr.github.io/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](http://up-for-grabs.net/)
+* [貢獻忍者](https://contributor.ninja)
+
+### **提交貢獻前應做的檢查清單**
+
+當你找到了你打算貢獻的專案時，在有任何行動之前，先整體做個瀏覽，確保專案是願意接受貢獻的。否則，你辛勤的工作可能沒有任何的回報。
+
+以下是一個簡易的檢查表，用來評估一個專案是否適合新的貢獻者。
+
+**符合開源的定義**
+
+
+
+
+
+
+**專案是否積極地接受各方的貢獻**
+
+在 master branch 上看看提交的活躍度。在 GitHub 上託管的開源專案，你可以在專案主頁上看到這些訊息。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+接下來，就是看專案 issue 的數量。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+同樣再來看看 PR 的情形。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**專案是友善的**
+
+一個專案的友好程度意味着更能接納新的貢獻者。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## **如何提交成果**
+
+你已經找到了你喜愛的專案，也已準備好貢獻了，接下來就剩思考如何以一個適當的方式去貢獻。
+
+### **有效溝通**
+
+無論你只是一次性的貢獻，或是決定長期參與社群，在開源的世界裡，學會如何與他人共事是很重要的技能之一。
+
+
+
+在你提出一個 issue 或 PR 之前，或者是在聊天室提問之前，請謹記下面所列出的幾點建議，會讓你的工作更有效率。
+
+**交代來龍去脈。** 以便於讓其他人能夠快速的理解。比方說執行程式時遇到一個錯誤，你要解釋你是當時是想做甚麼，並描述如何做才能重現錯誤。又比方說你是提交一個新的想法，你要解釋爲什麼這麼想，為什麼你認為這點子對專案會有幫助（而不是只對你有幫助！）
+
+> 😇 _"當我做 Y 的時候 X 功能沒有正常運作"_
+>
+> 😢 _"X 出問題! 請修好它。"_
+
+**在進一步行動前，做好準備工作。** 不知道沒關係，但至少你要先嘗試過、努力過。在尋求幫助之前，請確認閱讀了專案的 README、文件、issue（open 的和 closed 的）、郵件列表，並在網絡上查查看。當你表現出很強烈的求知慾時，人們會很樂意的幫助你的。
+
+> 😇 _"我不確定 X 是如何做到的，我查閱了說明文件，但沒有找到相關的介紹。"_
+>
+> 😢 _"我該怎麼做 X 這件事?"_
+
+**溝通時力求精簡明瞭。** 就像發送一份郵件、每一次的貢獻，無論是多麼的簡單，都是需要他人去檢閱的。很多專案都是請求的人多，提供幫助的人少。保持簡潔，能讓你得到他人幫助的機會大大增加。
+
+> 😇 _"我很樂意寫 API 的教學。"_
+>
+> 😢 _" 有一天開車在高速公路上，停在某個加油站加油的時候，我突發奇想，覺得我們應該這麼做，在進一步解釋之前，我先和大家展示一下… "_
+
+**盡量讓溝通都是在公開場合下進行。** 盡量不要發私訊給維護者，雖然很多人會想這樣做，除非是你要分享一些機敏資訊（諸如安全問題或有人嚴重的違反行為準則）。你若能夠保持談話是公開的，很多人可以從彼此交換的意見中學習和受益。
+
+> 😇 _（評論） "@維護者 你好！我們該如何處理這個 PR ？"_
+>
+> 😢 _（郵件） "你好，非常抱歉發信給你，但是我實在很希望你能看一下我提交的 PR 。"_
+
+**大膽的提問（但是要有耐心！）。** 每個人參與社群，開始的時候都是新手，哪怕是經驗老到的貢獻者也一樣，在剛進入一個新專案的時候，也是新手。出於同樣的原因，長期維護的人也並不一定都熟悉專案的每一個部分。協作時表現出你的耐心，你也會得到同樣的回報。
+
+> 😇 _"感謝你檢查了這個錯誤，我按照您的建議做了，這是輸出結果。"_
+>
+> 😢 _"你爲什麼不處理我的問題？這不是你的專案嗎？"_
+
+**尊重社群的決定。** 你的想法可能會和社群的優先順序、願景有所差異，他們可能回覆了你的想法或最後決定不採納你的建言，這時你應該去積極討論並尋求折衷的辦法，維護者必須慎重的考慮你的想法。但是如果你實在是不能同意社群的做法，你還是可以堅持己見將專案分支（fork）出去另起爐灶。
+
+> 😇 _"雖然我很遺憾你不能支援我的需求，但是你解釋這只是對一小部分使用者起作用，我理解你的理由。感謝你的耐心傾聽。"_
+>
+> 😢 _"你爲什麼不支援我的需求？這真是難以接受！"_
+
+**以上幾點，要銘記在心。** 開源是由來自世界各地的人們共同協作實現的。需要面對跨語言、跨文化、不同的地理位置、不同的時區的問題，另外，單純文字上的溝通無法傳達語氣和情緒。就先假設這些對話都充滿善意吧。不用害怕拒絕人家，詢問事情的狀況，進一步澄清你的立場。試著讓網路世界成為一個更好的地方。
+
+### **多了解來龍去脈**
+
+在正式開始之前，做一些快速檢查，也許有人已經討論過你的疑惑了。瀏覽專案的 README、issue（ open 和 closed 都算）、郵件列表、Stack Overflow。毋需去花好幾個小時去全部折騰一遍，但是用幾個關鍵字搜尋一下是必要的。
+
+如果你沒有找到和你想法一樣的內容，你就可以開工了。如果專案是在 GitHub 上的話，你可以開啓一個 issue 或 PR：
+
+* **Issues** 開啓一次對話或討論
+* **Pull requests** 請求接受自己的解決方法
+* **簡單的溝通** ，例如澄清或 how-to 的問題，嘗試到 Stack Overflow 、IRC、Slack 或其它聊天頻道問問看。
+
+在你創建 issue 和 PR 之前，請檢查專案的貢獻者文件（文件名通常叫做 CONTRIBUTING，或者就直接寫在 README 中），找到你需要、較具體的東西，例如他們會要求你遵循某個樣板，或者是要求你使用某個測試。
+
+如果你想做一個重大的貢獻，在正式開始之前先創建一個 issue。監控專案是很有幫助的（在GitHub，[點擊 "Watch"](https://help.github.com/articles/watching-repositories/) ，所有當中的對話都會通知你），通知社群的成員們，讓大家知道你要做的工作，免得你做了之後，他們事後才知道。
+
+
+
+### 提出問題
+
+你應該在遇到下列情況時，去創建一個 issue：
+
+* 報告一個你自己無法解決的錯誤
+* 討論一個重要的主題或想法（例如：社群、遠景、政策等）
+* 提議做一個新的功能，或者其它專案的想法
+
+在 issue 的溝通中幾點實用的技巧：
+
+* **假如你看到一個 open 的 issue，也是你打算解決的**，寫下留言，告訴其他人你要開工了。這樣的話，可以避免與其他人做了重複的事情。
+* **假如某個 issue 已經處於 open 的狀態很久了**，可能是有人正在處理中，又或者是已經解決了，也請你留言確認一下事情的狀態再決定下一步。
+* **假如你創建了 issue ，但是沒多久自己解決了**，也要留言，讓其他人知道，然後結束該 issue 。記錄本身就是爲社群的貢獻。
+
+### **創建 pull request**
+
+在下面的情形時，請你務必使用 PR：
+
+* 提交簡易的補丁 (例如拼寫錯誤、失效的超連結、或者是其它較明顯的錯誤)
+* 開始一項別人請求的任務，或者是過去在 issue 中早就討論過的事情
+
+一個 PR 並不代表工作已經完成了。它通常是儘早開啓一個 PR ，這樣其他人可以了解或者給你一些回饋。只需要標記爲 "WIP"（Working in Progress）。你可以隨時添加任何留言。
+
+如果說專案是託管在 GitHub 上，以下是我們對於提交 RP 的建議：
+
+* **[Fork 程式碼](https://guides.github.com/activities/forking/)** 並下載到自己的電腦，在本地端設定「上游」爲遠端倉庫。這樣你可以在提交你的 PR 時保持和「上游」同步，合併時會減少解決衝突的時間。（更多關於同步的說明，請參考[這裡](https://help.github.com/articles/syncing-a-fork/)。）
+* **[創建一個分支](https://guides.github.com/introduction/flow/)** 方便自己編輯。
+* **參考任何相關的 issue**或在你的 RP 中註記相關的文件（例如："Closes #37."）
+* **留下更動前後的螢幕截圖**，如果你修改了 HTML/CSS。在你的 PR 中放上截圖。
+* **測試你的工作！**用原本寫好的測試來跑你寫好的新功能，若沒有的話，則需要寫一個測試。無論是否有測試，一定要確保你的改動不會弄壞現有的專案的功能。
+* **和專案現有的風格保持一致**，盡你最大的努力，在使用縮排、分號或註釋很可能和你自己的風格大相徑庭，但這是為了節省維護者的精力，為了以後要了解、維護時的方便。
+
+如果這是你第一次提交 PR。可以瀏覽[提交 PR](http://makeapullrequest.com/)的文件，這是 @kentcdodds 專門爲初次創建 PR 的人寫的手把手教學。
+
+## **提交後需要善後的事宜**
+
+你做到了！恭賀你成爲貢獻開源的一員。希望這是一個好的開始。
+
+在你提交了貢獻之後，下面幾種情形中的某種是可能發生的：
+
+### 😭 **沒有人理你。**
+
+希望你在工作開始之前[檢查過了專案的活躍度](./#提出問題)，不過有時即使檢查過了，在一個活躍的專案中沒有人理會你的貢獻也是很正常的。
+
+如果過了一週，依舊沒有人回應，請心平氣和的在同個條目下留言，請人幫你審核。如果你知道可以找誰審核，你可以使用 @名字，提醒他一下。
+
+**千萬不要**私下去聯絡他人；要記住開源專案裡，所有的溝通都應該是公開的。
+
+如果還是沒有人回覆，那就是真的沒有人對你的貢獻做出回應。這可能感覺很差，但千萬不要灰心。每個人都會遇到這樣的情況。有很多原因會導致沒人回應你，這些原因通常也不是你能控制的。再接再厲，換一種方法去提交，或者換一個專案。這也是一個好時機讓你決定不要投資太多時間在成員活動不活躍的專案。
+
+### 🚧 **有人希望你修改你的貢獻。**
+
+被人要求修改你的貢獻是很常見的事情，可能是改變你的提議，或是修改程式碼。
+
+當有人提出變更時，請及時回覆。畢竟他們花時間看了你的工作。開了一則 PR ，然後一走了之是一個壞習慣。如果你不知道如何改，花點時間研究，如果還是沒有想到好辦法，那麼是該向他人求助的時候了。
+
+如果你沒時間處裡一則 issue （舉例來說，如果對話已經持續了一個月了，而你還有其他的事情要處裡），那麼請通知維護的人，你無法及時的回覆了，肯定有人非常樂意接替你的工作的。
+
+### 👎 **你的貢獻沒有被採納。**
+
+你的工作最後可能沒有被接受。希望你沒有為此花太多力氣。如果你不確定爲什麼沒有被接收，這正是一個很好的機會，去詢問維護者的看法、給他們一個澄清的機會。無論如何，你都要對他們的決定表示尊重。別花時間在爭論或樹立敵人上。如果你堅持自己，你還是可以隨意 fork 專案，按照自己的思路發展出分支來。
+
+### 🎉 **你的貢獻被接受。**
+
+太棒了！你完成了一次開源貢獻！
+
+## 你辦到了!
+
+不論你是第一次貢獻，還是正在嘗試其他的貢獻方式， 希望本文有提供你一些靈感去實踐。即便你的貢獻沒有被採納，別忘了對幫助過你的維護者表示感謝。開源就是由你這樣的人所打造：一則 issue、一則 PR或透過留言討論。
diff --git a/_articles/zh-tw/index.html b/_articles/zh-tw/index.html
new file mode 100644
index 00000000000..9e1eeb91162
--- /dev/null
+++ b/_articles/zh-tw/index.html
@@ -0,0 +1,5 @@
+---
+layout: index
+lang: zh-tw
+permalink: /zh-tw/
+---
diff --git a/_articles/zh-tw/leadership-and-governance.md b/_articles/zh-tw/leadership-and-governance.md
new file mode 100644
index 00000000000..35ac7618a43
--- /dev/null
+++ b/_articles/zh-tw/leadership-and-governance.md
@@ -0,0 +1,158 @@
+---
+lang: zh-tw
+title: 領導與治理
+description: 有了正式規則的決策，可讓開源專案順利的成長。
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+ - best-practices
+ - metrics
+---
+
+## 針對增長的專案來理解治理
+
+當專案開始有條不紊的進行，人員也開始穩定，那麼你就應該開始社群的治理了。對於社群的治理，你或許有一些疑問，諸如如何將常規專案的貢獻者納入你的工作流？如何才能判斷應該賦予誰提交的權限？又或者是如何解決社群的債務？如果你對這些有疑問的話，我們這裏會盡力幫你解決。
+
+## 開源專案中通常都有那些角色
+
+很多專案針對貢獻者角色和身份均遵循相似的結構。
+
+這些角色實際上意味着什麼完全取決於你。我們這裏所列舉的，相信你是非常熟悉的了：
+
+* **維護者**
+* **貢獻者**
+* **修訂者**
+
+**對於某些專案來說， "維護者"** 就是唯一擁有提交權限的人。然而在其它的一些專案中，維護者會列在README上
+
+作爲一名維護者，不一定非得一定要爲專案撰寫程式。有可能是專案的佈道師，爲專案的宣傳做了很多的工作，又或者是撰寫文件讓更多的人參與進來。不管他們每天做什麼，維護者就是那些對專案方向負責的人，並致力於專案的改進。
+
+**作爲 "貢獻者" 可以是任何人** ，只要提出issue或PR 就叫做貢獻者，那些爲專案作出有價值的都算（無論是分類問題，編寫程式還是組織會議），又或者是將他們的PR合並進主乾的（或許這個定義是最接近所謂的貢獻者的）。
+
+
+
+**術語 "修訂者"** 可能用於區分其他形式的貢獻的提交訪問，這是一種特定類型的責任。
+
+其實你可以根據自己喜歡的方式來定義專案的角色，[考慮使用更廣泛的定義](../how-to-contribute/#具體而言什麼是貢獻) 來鼓勵更多的形式的貢獻。無論技術技能如何，您都可以使用領導角色來正式識別爲您的專案做出突出貢獻的人員。
+
+
+
+## 該如何將這些領導力角色正規化
+
+將領導力角色正規化，可以幫助人們找到歸屬感，且可以讓其它社群成員明白應該找誰能夠獲得幫助。
+
+對於一個較小的專案來講，指定領導者，只需要在 README 或 CONTRIBUTORS 文本文件中寫上他們的名字即可。
+
+對於稍大型點的專案，如果你已經擁有了網頁的話，那麼請創建一個團隊的頁面，或者創建一個團隊領導的頁面。舉例來說， [PostgreSQL](https://github.com/postgres/postgres/) 就擁有一個[很全面地團隊頁面](https://www.postgresql.org/community/contributors/) ，而且每位貢獻者都擁有簡短的介紹。
+
+如果你的專案擁有非常活躍的貢獻者社群，你或許會專門建立一個維護者的"核心團隊"，甚至是根據不同的話題所有者成立子的委員會（例如，安全，問題篩選，或者是社群準則）。讓人們自行組織、且能夠讓志願者自行找到自己喜歡的角色，而不是去分配他們。
+
+
+
+領導者團隊或許要創建一個指定的頻道（如IRC），又或者是參與專案的日常討論（如Gitter或Google Hangout）。你需要將這些會議可以公開訪問，以便讓人們方便傾聽。舉例來說，
+ [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)就會[每週開一次會議，每次持續幾小時](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+
+一旦你建立了領導力角色，一定不要忘記撰寫文件，告訴人們如何成爲領導者！要爲如何成爲一名維護者或加入到專案的子委員會創建一個清晰的流程，並將之寫入 GOVERNANCE.md 文件。
+
+諸如[Vossibility](https://github.com/icecrime/vossibility-stack) 這樣的工具，可以幫助你追蹤誰是（或不是）專案的貢獻者。爲這些資訊作說明，以避免社群出現維護者作出私自的決定。
+
+另外，如果你的專案在託管在GitHub上，考慮將你的專案從個人賬戶遷移到某個組織，而且要爲組織增加額外的一個備份的管理員。
+[GitHub 上的組織](https://help.github.com/articles/creating-a-new-organization-account/) 能夠讓權限管理和多倉庫管理更加的輕鬆，而且可通過 [共享所有權](../building-community/#分享專案的所有權)來保護你的專案。
+
+## 何時該賦予提交者權限
+
+有的人認爲專案應該對所有人都開放提交訪問，從而讓任何人都可以做出貢獻。理由是這樣做的話，會讓人們感到擁有這個專案，進而達到鼓勵的目的。
+
+換句話說，尤其是針對那些大型的、更加複雜的專案，你或許只是會給那些證明自己有能力提交程式碼的人賦予權限。這個沒有一個確切的衡量標準，做你認爲正確的就好了，或者是最讓專案成員感到舒服的方式。
+
+假如專案是託管在GitHub上，可以使用[受保護的分支](https://help.github.com/articles/about-protected-branches/)來管理那些可以提交特定的分支情況。
+
+
+
+## 對於開源專案來說有那些常見的治理結構
+
+關於開源專案有三類通用的相關治理結構。
+
+* **BDFL:** BDFL 是 "仁慈的獨裁者生活" 的縮寫. 在此結構下，有一個人（通常是專案的最初的作者）擁有專案中所有的最後決定權。[Python](https://github.com/python) 就是一個非常經典的例子。較小的專案可能默認就是 BDFL 結構，因爲他一般就是一到兩位維護者。若是公司組織的專案也極有可能會採用BDFL結構。
+
+* **精英制:** **(注: 術語 "精英制" 對於一些社群可能具有消極的含義，其擁有較[複雜的社會和政治的歷史](http://geekfeminism.wikia.com/wiki/Meritocracy).)** 在精英制下，活躍的專案貢獻者（他們用行動證明自己是"精英"）給一個正式的決策作用，決定通常會基於純粹的投票一致性。精英制的概念首次由[Apache Foundation](http://www.apache.org/)提出；[所有的Apache 專案](http://www.apache.org/index.html#projects-list) 都是基於精英制的。貢獻者只能代表自己是獨立的個體，不可以是公司。
+
+* **自由貢獻:** 在自由貢獻的模式下，做最多工作的人通常被認爲是最具影響力的，但是是基於當前的工作，而不是歷史的共享。專案的重大決策是基於尋求共識的過程（對不同的聲音要討論）而不是純粹的投票，儘可能的努力的去囊括多的社群觀點。較流行的使用自由貢獻模式的專案有[Node.js](https://nodejs.org/en/foundation/) 和 [Rust](https://www.rust-lang.org/en-US/)。
+
+應該選擇哪一種模式了呢？由你自己來做決定！每個模式都有優點，也有缺點。雖然上面的描述乍一看，這三種模式有着很大的不同，其實不然，它們還是有着共同點的。如果你對上述三種模式有興趣，可以採用下面的模版：
+
+* [BDFL 模式模版](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [精英模式模版](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js 的自由貢獻規則](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79)
+
+## 當我創建開源專案時，需要專門撰寫一份治理文件嗎
+
+其實沒有什麼合適的時間來撰寫專案的治理，但是可以根據社群的動態來進行恰當的定義。開源治理最好的也是最難的部分是有社群本身來塑造！
+
+在專案的治理中，一些早期的文件將會不可避免的，然而也不必太強求，寫下你所能夠想到的。舉例來說，你可以將某些預期的行爲定義清楚，貢獻的流程是如何的，或者專案是如何啓動的，等等。
+
+如果你自己是公司所啓動開源的一部分，在啓動之前，應該做一些討論，如公司將會如何維護專案，隨着專案的發展，決策該如何定奪。你可以會公開的解釋一下，貴公司將如何參與（或不參與）該專案。
+
+
+
+## 公司員工該如何開啓提交貢獻之旅？
+
+成功的開源專案，會有很多的用戶和公司使用，而且有一些公司的主要收入和專案是綁在一起的。舉例來說，某公司在其商業產品或服務中使用了開源專案的程式碼作爲其一個組件。
+
+一個專案越是被廣泛的使用，有相關背景的專業人士的需求就會上升，**你或許就是其中之一**，那麼就順勢成爲繼續爲開源專案做事，還有一定的報酬。
+
+將商業的活動視爲正常不過的事情很重要，它也只是程式碼的開發方法之一。爲開發者付費不應該被特殊的對待，好像程式碼必須是無償開發的才行；每個貢獻都必須有技術的衡量標準來進行評估。人們應該在這些商業的活動中感到非常的自在，而且針對特定的增強或功能項討論時也應是坦蕩的、自然的。
+
+"商業" 是完全和"開源"相容的。"商業"僅僅是意味着某些地方有錢的參與 —— 就是說軟體被用於了商業行爲，也就是說專案被採用獲得了認可。（當開源軟體被用於非開源產品的一個部分時，這個整體的產品仍然是"專有的"軟體，因爲開源，它可以用於商業或非商業的目的。）
+
+和這個世界上很多的其它商業產品一樣，商業能夠激勵開發者去積極的貢獻於專案，通過他們靠譜的提交貢獻。顯而易見的是，一位因花了自己的時間和精力的開發者獲得報酬，理應比沒有獲得報酬的更具持久性，當然，這對於某些聖徒是不成立的，或者這麼說吧，報酬是能體現一個貢獻度的衆多衡量因素的其中之一。所以將你的專案討論聚焦於貢獻上，不要讓人們分散精力去思考或做其它的事情。
+
+## 我是否需要一個法律實體來支持我的專案
+
+除非你特別的有錢，其實你根本沒有必要爲開源專案而專門搞一個法律實體來支持。
+
+舉例來說，假如你打算創辦自己的商業公司，（假如是在美國的話）你需要成立一家集團公司或有限責任公司。如果你只是爲你的開源專案做一些合約的工作，你可以以投資人的身份接受錢財，或者成立一家有限責任公司（如果是在美國的話）。
+
+如果你打算讓自己的開源專案接受捐贈的話，你可以創建一個捐贈按鈕（使用PayPal或Stripe，舉例來說），但是你要知道，這些錢並非是免稅的，除非你是認證過的非盈利性組織（在美國的話，諸如501c3）。
+
+很多專案都不願意成立非盈利組織那麼麻煩，所以他們會以贊助商的身份尋找一個非營利性組織。財政資助代表你接受捐款,通常以換取一定比例的捐贈。針對開源專案接受財政資助的非營利性組織有很多，如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金會](http://www.apache.org/), [Eclipse 基金會](https://eclipse.org/org/foundation/), [Linux 基金會](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) 等等。
+
+
+
+如果你的專案是和某特定的語言或生態系統緊密相連的，那麼你可以直接在相關的軟體基金會下工作。例如，[Python 軟體基金會](https://www.python.org/psf/) 就幫襯著專案 [PyPI](https://pypi.python.org/pypi)，這是一塊優秀的Python包管理器，又比如[Node.js 基金會](https://nodejs.org/en/foundation/) 支撐着 [Express.js](http://expressjs.com/)，一款基於Node的框架。
diff --git a/_articles/zh-tw/legal.md b/_articles/zh-tw/legal.md
new file mode 100644
index 00000000000..e4e23684551
--- /dev/null
+++ b/_articles/zh-tw/legal.md
@@ -0,0 +1,156 @@
+---
+lang: zh-tw
+title: 開源的法律保障
+description: 對於開源你應該瞭解的法律知識。
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+ - contribute
+ - leadership
+---
+
+## 瞭解開源的法律含義
+
+向世界分享你們具有創造性的工作，這是一個多麼令人激動和有價值的經歷。這也意味著你們必須擔心一堆你們不清楚的法律問題。幸運的是，你們不必從頭開始。我們已經涵蓋了你們的法律需求。（在你們行動前，請確定閱讀了我們的[免責聲明](https://github.com/cnbo/open-source-guide/blob/gh-pages/notices.md)。）
+
+## 爲什麼大家非常擔心有關開源的法律問題
+
+很高興你們提問！當你們行創造性工作（例如寫作，圖形或程式碼）時，默認情況下該作品屬於專有版權（copyright）。也就是說，法律承認你們是你們作品的作者，他人在沒有經得你們同意的情況下不能使用你們的工作。
+
+一般來說，這意味著沒有人可以在沒有你們授權的情況下使用，複製，分發或者修改你們的工作。
+
+然而，開源有著不一樣的情況。因爲作者希望他人使用，修改以及分享他們的工作。但因爲法律默認依然是專有版權（copyright），所以你們需要一個明確說明這些權限的協議。
+
+如果你們不應用開源許可協議，那麼對你們專案做出貢獻的人也都將成爲其工作的專屬版權（copyright）所有者。這意味著沒有人（也包括你們）可以使用，複製，分發後者修改他們的貢獻，
+
+最後，你們的專案可能具有你們不知道的許可證要求的依賴關係。你們的專案社群，或者你們的僱主政策也可能要求你們使用特定的開源許可協議。
+
+## 公開的GitHub專案是開源的嗎
+
+當你們在GitHub上[創建一個新專案](https://help.github.com/articles/creating-a-new-repository/) 時，你們可以選擇將倉庫設置成**private**或者**public**。
+
+
+
+**讓你們的GitHub專案公開與許可你們的專案是不同的。**公開專案是由[GitHub的服務條款](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership)保護，它允許他人瀏覽以及fork你們的專案，但是沒有權限參與你們的工作。
+
+如果你們想讓他人使用，複製，修改你們的專案，或者參與貢獻你們的專案，那麼你們的專案就需要包含一個開源許可協議。例如，即使你們的專案是公開的，但沒有你們的授權，一些人是不能合法在他們的程式碼中使用你們GitHub專案中的任何部分。
+
+## 請告訴我該如何保護專案
+
+你們很幸運，開源許可協議已經標準化了同時使用簡單。你們可以直接複製粘貼一個已經存在的許可協議到你們的專案裏。
+
+[MIT](https://choosealicense.com/licenses/mit/)，[Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)和[GPLv3](https://choosealicense.com/licenses/gpl-3.0/)都是非常流行的開源許可協議，但是也有其它選擇。你們可以在[choosealicense.com](https://choosealicense.com/)上找到這些許可協議的全部文本，同時說明了如何使用他們。
+
+當你們在GitHub上創建了一個新專案，你們會被[要求添加一個許可協議](https://help.github.com/articles/open-source-licensing/)。
+
+
+
+## 哪個開源許可協議適合我的專案
+
+如果你們是小白，那麼使用[MIT License](https://choosealicense.com/licenses/mit/)，不容易出錯。它很短，很容易理解，並允許任何人做任何事情，只要他們保留許可證的副本，包括你們的版權聲明。如果你們需要，您們能夠根據不同的許可協議發佈專案。
+
+然而，爲專案選擇合適的開源許可協議這取決於你們。
+
+你們的專案非常可能有（或將有）**依賴**。例如，如果你們開源了一個Node.js的專案，你們將可能使用來自npm（Node Package Manager）的庫。你們依賴的這些庫都有它們自己的開源許可協議。如果他們的許可協議"允許"（對使用，修改和分享給予公共權限，而對有關專案的許可協議沒有要求），這樣你們就可以使用任何你們想要的許可協議。共同允許許可協議包括MIT，Apache 2.0，ISC和BSD。
+
+另一方面，如果你們的依賴中有一個的許可協議是"強硬的copyleft"（他們也給同樣的允許，但條件是有關專案得使用同樣的許可協議），那麼你們的專案將使用與之相同的許可協議。copyleft許可協議包括GPLv2，GPLv3和AGPLv3。
+
+你們也會想到考慮希望你們的社群使用以及貢獻你們的專案：
+
+* **你們是否想讓你們的專案成爲其它專案的依賴？**在你們的相關社群最好儘可能使用最流行的許可協議。例如，[MIT](https://choosealicense.com/licenses/mit/)是[npm libraries](https://libraries.io/npm)使用的最流行的許可協議。
+* **你們的專案是否想吸引大企業？**大型企業可能需要所有貢獻者的明確專利許可。在這種情況下，[Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)適合你們。
+* **你們的專案是否想吸引不願自己的貢獻用於其它同類型軟件的貢獻者？**[GPLv3](https://choosealicense.com/licenses/gpl-3.0/)和[AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)適合你們。
+
+你們的公司可能爲自己的專案準備了特定的許可協議。例如，它可能需要許可許可證，以便公司可以在公司的閉源產品中使用你們的專案。或者你們的公司要求強大的copyleft許可協議同時要求貢獻者贊成，這樣專案只屬於你們公司，沒有人能在有關的軟件中使用你們的專案。或者你們的公司可能有與標準，社會責任或透明度相關的某些需求，其中任何一個都可能需要特定的許可策略。與你們[公司的法律部門](#公司的法律團隊需要知道什麼)談談。
+
+當你們在GitHub上創建了一個新專案，它給你們提供了選擇許可協議的機會。包括上面提到的可以使你們的GitHub專案開源的許可協議。如果你們想要瞭解其他選擇，可以通過查閱[choosealicense.com](https://choosealicense.com)找到適合你們專案（即使它[不是軟體](https://choosealicense.com/non-software/)）的許可協議。
+
+## 如果我想更換專案的許可協議，該怎麼辦
+
+大多數專案絕不需要更換許可協議。但是情況偶爾有變。
+
+例如，隨著你們專案的壯大，它添加了新的依賴或用戶，或者你們的公司改變了策略，或者其他的要求要更換不同的許可協議。如果你們在開始專案的時候沒有添加許可協議，那麼再添加一個許可協議和更換許可協議是一樣的效果。當你們要添加或者更換專案的許可協議時，需要考慮以下三件事：
+
+**這件事很複雜。**確定許可協議的兼容性和合規行，以及誰擁有版權，這會非常快速地變得複雜和混亂。爲新的發佈和貢獻選擇一個新的且合適的許可協議與重新許可已存在的貢獻是不同的。一旦你們有任何想改變許可協議的想法，請首先讓法律團隊知道。即使你們已經或者能獲得可以更換許可協議的權限，請考慮者會給專案的其他用戶和貢獻者帶來怎樣的影響。將更換許可協議視爲"管理事件"，只有通過與專案的利益相關者進行明確的溝通和諮詢，才更有可能順利進行。請謹記，從一開始就爲你們的選擇和使用合適的許可協議。
+
+**你們的專案已經有了許可協議。**如果專案的現有許可證與您要更改的許可證兼容，則可以開始使用新許可證。這是因爲如果A許可協議與B許可協議兼容，你們將遵守A的條款，同時遵守B的條款（但不一定反之亦然）。因此，如果你們目前正在使用許可型的許可協議（例如MIT），則可以更改爲具有更多條件的許可協議，只要你們保留MIT許可協議的副本和任何相關的版權聲明（即繼續遵守MIT許可協議的最低條件）。如果你們現在的許可協議不是許可型的（例如，copyleft或者你們還沒有許可協議）以及你們不是版權的唯一所有者，那麼你們不能將許可協議改爲MIT。基本上，只要是使用的許可型的許可協議，版權所有者能事先更換許可協議。
+
+**你們的專案已經有版權所有者。**如果你們是你們專案的唯一貢獻者，然後你們或者你們的公司是專案版權的唯一所有者。你們可以添加或更換任何你們或者你們公司心儀的許可協議。不然你們需要取得其他版權所有者的同意。他們是誰？他們是已經參與你們專案提交的人。但有些情況是專案版權掌握在這些人的僱主手中。在某些情況下，人們只是做了_微小的_貢獻，但沒有硬性規定，在一些行程式碼下的貢獻不受版權保護。對與這樣的情況該怎麼辦？對於一個相對較小以及年輕的專案來說，取得所有貢獻者對更換許可協議的同意是可行的。。但對於大專案和老專案來說，你們必須尋求很多貢獻者以及他們繼承者的共識。Mozilla花費了多年重新授權Firefox，Thunderbird和相關軟件。
+
+或者，你們可以讓貢獻者事先同意（通過額外的貢獻者協議 - 見下文）在某些條件下更改某些許可協議，這些更改將超過現有的開源許可協議。這會改變許可協議改的複雜性。如果在執行許可協議更改時，你們仍然想要和專案利益相關者進行溝通，你們需要從你們律師那得到更多幫助。
+
+## 我的專案需要額外的貢獻者協議嗎
+
+可能不要。對於大多數的開源專案，一個開源許可協議可作用與所有貢獻者和用戶。
+
+貢獻者協議會給維護者帶來額外的管理工作。這些協議增加了多少工作得取決去專案和實施。簡單的協議可能要求貢獻者確認和點擊，在專案的開源許可協議下他們有權利貢獻。更複雜的協議可能需要法律的審查和貢獻者的僱主的簽字。
+
+此外，貢獻者協議有時被認爲對專案社群不友好。他們也增加了人們參與社群的障礙。
+
+
+
+一些情況下你們可能想要爲你們的專案考慮一個額外的貢獻協議：
+
+* 你們的律師想要所有的貢獻者明確接受貢獻者條款，或者因爲他們覺得只有開源許可協議還遠遠不夠。如果這是唯一的問題，那麼有肯定專案開源許可協議的貢獻者協議就足夠了。[jQuery個人貢獻者許可協議](https://contribute.jquery.org/CLA/)就是一個很好的輕量級的個人貢獻者協議。對於一些專案來說，[Developer Certificate of Origin](https://github.com/probot/dco)是一個很好的先例。
+* 你們的專案使用的開放源許可協議不包括明確的專利授權（如MIT），你們需要所有貢獻者的專利授權，這些可能適合用於你們公司的專利組合或者專案的其他貢獻者和用戶。[Apache 個人貢獻者許可協議](https://www.apache.org/licenses/icla.txt)是一種常用的附加貢獻者協議，其具有與Apache許可2.0中的專利許可相同的專利許可。
+* 如果你們的專案使用的是copyleft許可協議，但你們也需要分發專案的專有版本。那你們需要每個貢獻者分配版權給你們或者授予你們許可權。[MongoDB貢獻者協議](https://www.mongodb.com/legal/contributor-agreement)就是這中類型的。
+* 你們認爲你們的專案在其有效期內需要更換許可協議，以及事先得到貢獻者的同意。
+
+如果您們實需要在您的專案中使用額外的貢獻者協議，請考慮使用諸如CLA助手之類的集成，以最大限度地減少貢獻者的分心。
+
+## 公司的法律團隊需要知道什麼
+
+作爲一名公司的僱員，如果你們在發佈一個開源專案，你們首先需要讓法律團隊知道。
+即使只是一個個人專案，請考慮讓他們知道。你們可能和公司有一個"員工知識產權協議"，這給了公司一些對你們專案的控制權，特別是當專案和公司的業務有著很多的聯繫或者你們使用公司的資源發展專案。你們的公司_應該_很容易給們許可，也許已經通過一個員工友好的知識產權協議或公司政策。如果不是這樣，你麼可以談判（例如，解釋你們的專案爲公司的專業學習和發展目標服務），或者你們在找到一個更好的公司前停止你們專案的工作。
+
+**如果你們的開源專案是爲了你們的公司，**絕對需要讓他們知道。根據公司的業務需求和專業知識，你們的法律團隊可能已經制定了有關開放源程式碼許可協議（以及可能還有其他貢獻者協議）的政策，以確保您的專案符合其依賴關係的許可協議。如果不是這樣，你們和他們很幸運！你們的法律團隊應該渴望與你們合作，把這個東西搞清楚。你們需要思考這些事：
+
+* **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些事開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](https://choosealicense.com/no-license/#for-users)，要是你們得不到許可，你們只能停止使用他們的程式碼。
+
+* **商業機密：**請考慮專案中是否有公司不想對外公開的東西。如果是這樣的話，你們只能開源專案的一部分，得保護好公司的商業機密。
+
+* **專利：**你們公司是否申請了與你們專案有關的專利？如果開源源程式碼，這會對公司的專利進行[公開披露](https://en.wikipedia.org/wiki/Public_disclosure)。可悲的是，你們可能被要求等待（或者公司會重新思考應用程序）。如果你們期望從擁有大量專利組合的公司的員工那裏得到貢獻，們的法律團隊可能希望你們使用來自貢獻者的明確專利授權的許可協議（例如Apache 2.0或GPLv3）或其他貢獻者協議（見上文）。
+
+* **商標：**認真檢查你們的專案名[沒有與已經存在的商標衝突](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#避免命名衝突)。如果你們將自己公司的商標用於專案，請檢查它有沒有造成衝突。[FOSSmarks](http://fossmarks.org/)是在自由和開源專案的背景下理解商標的實用指南。
+
+* **隱私：**你們的專案是否收集了用戶數據並存儲到公司的服務器？你們的法律團隊可以幫助你們遵守公司政策和外部法規。
+
+如果你們發佈了公司的第一開源專案，爲了能通過，以上這些綽綽有餘（不要擔心，大多數專案不會引起重大關注）。
+長期來說，們的法律團隊可以做更多的事情，以幫助公司從開源中獲得更多，並保持安全：
+
+* **員工貢獻策略：**考慮制定一個公司策略，指明你們的員工如何爲開源專案貢獻。明確的政策將減少你們員工的迷惑，並幫助他們爲公司的最佳利益向開源專案做貢獻，無論是作爲他們工作的一部分還是在自由時間。Rackspace的[Model IP和開源貢獻策略](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)就是很好的示例。
+
+
+
+* **發佈什麼：**[（幾乎） 所有？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)如果你們的法律團隊瞭解並投資於你們公司的開源策略，他們將是你們最好的幫助，而不是阻礙你們的努力。
+* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。
+
+
+
+* **專利：**你們的公司可能希望加入[開放發明網絡](http://www.openinventionnetwork.com/)，一個共享的專利防禦池，以保護成員使用主要開源專案，或探索其他替代專利許可。
+
+* **管理：**特別是當如果將專案轉移到公司以外的法律實體是有意義的。
diff --git a/_articles/zh-tw/metrics.md b/_articles/zh-tw/metrics.md
new file mode 100644
index 00000000000..6110ae4feda
--- /dev/null
+++ b/_articles/zh-tw/metrics.md
@@ -0,0 +1,126 @@
+---
+lang: zh-tw
+title: 開源衡量準則
+description: 透過持續的追蹤專案，幫助你做出最佳決策，讓開源專案更成功。
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## 爲何要度量所有
+
+數據，只有在充滿智慧的運用它，才能發揮出其應有的功效。作爲一名開源專案的維護者，可以利用數據來助自己一臂之力。
+
+當獲取到很多的資訊之後，就可以做很多事，比如：
+
+* 理解用戶對一個新功能是怎麼反應的
+* 搞清楚新用戶是從哪裏來的
+* 鑑別，並且決定是否支持一個跑偏的使用場景或者功能
+* 量化你專案的流行程度
+* 知道你的專案是怎樣被別人使用的
+* 通過贊助商或者讚賞掙點小錢
+
+舉個例子，[Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) 就利用Google數據分析，來幫助他們對工作進行了優先級的區分：
+
+> Homebrew 是免費的，完全由志願者在業餘時間維護。所以，我們沒有資源去做詳細的Hemobrew用戶調查從而決定如何更好的設計未來的新功能以及對當前的工作分出優先級。匿名的聚合用戶數據分析讓我們基於用戶如何，何地，何時使用Homebrew來優先考慮某些補丁和功能。
+
+流行程度並不能代表一切。每個人都是因爲不同的原因參與到開源專案中來，如果你做專案維護者的原因是展示你的工作成果，公開你的代碼，或者只是爲了好玩，那麼度量標準可能對你來說就不是那麼的重要。
+
+如果你想對自己的專案有一個深層次的瞭解，那麼請繼續閱讀下文介紹的分析專案活躍度的方法。
+
+## 發現專案
+
+在有人能夠使用或者回饋你的專案之前，他們得知道是否有這樣的專案存在，問問你自己：_人們都在尋找這樣專案嗎？_
+
+
+
+如果你的專案是託管在Github, 你可以[訪問](https://help.github.com/articles/about-repository-graphs/#traffic) 獲取諸如多少人訪問過你的專案，他們從哪裏得知的之類的資訊。在你的專案主頁，點擊"Graphs", 然後"Traffic"。在這個頁面，你可以看到:
+
+* **總瀏覽量:** 專案被查看了多少次
+
+* **總獨立訪問者:** 多少人查看了你專案
+
+* **關聯網站:** 訪問者從哪裏來的。這個數據能幫助你搞清楚哪裏可以接觸到你的受衆和你爲推廣做出的努力是不是有效的。
+
+* **受歡迎的內容:** 訪問者都查看了你專案的那些內容，按照頁面訪問量和獨立訪客數。
+
+[GitHub stars](https://help.github.com/articles/about-stars/) 可以提供一個基本的衡量流行度的標準。然而GitHub 點贊數並不和下載量、使用量直接掛鉤，但是他可以告訴你有多少人在關注你的專案。
+
+你也許想要[在特定的地方跟蹤可發現的內容](https://opensource.com/business/16/6/pirate-metrics): 舉個例子，Google PageRank，會跟蹤來自你專案網站的流量，或者跟蹤來自其他開源專案或者網站的流量。
+
+## 使用專案
+
+人們在這個廣袤而且瘋狂的我們稱之爲互聯網的地方，竟然找你了你的專案。理想情況下，當他們看到你的專案的時候，他們會情不自禁的做點什麼。第二個問題你要問自己的是：_人們在使用你的專案嗎？_
+
+如果你使用一個包管理器，比如說npm或者RubyGems.org，來發佈你的專案，你就可以跟蹤到下載量。
+
+每個包管理工具可能會對下載量有着大同小異的定義，而且下載量並不直接和安裝、使用有關，但是它提供了一個基本的比較標準。嘗試使用[Libraries.io](https://libraries.io/) 來跟蹤很多流行包管理工具的使用數據。
+
+如果你的專案是託管在Github上，再一次切換到"Traffic" 頁面，你可以用[clone graph](https://github.com/blog/1873-clone-graphs)看看你的專案在一個給定的日期被克隆了多少次，按照獨立克隆者的總克隆數排序。
+
+
+
+如果使用專案的數量低於發現專案的數量的話，那麼就有兩個問題值得考慮。他們是：
+
+* 你的專案沒有成功的轉化你的受衆，或者
+* 你吸引了錯誤的受衆
+
+舉個例子，如果你的專案佔據了Hacker News的頭版頭條，你可能會看到一個流量的高峰，但是與此同時，轉化率會比較低，因爲Hacker News上所有人都看見了你的專案。如果你的Ruby專案是在Ruby研討會上宣傳的，那麼，更有可能從目標受衆羣體中獲得較高的轉化率。
+
+努力找出你的受衆是從哪裏來的，然後在你的專案主頁尋求他們的反饋，看看是上述兩種情況的哪一種。
+
+一旦知道了都是有那些人在使用你的專案的話，接下來就是看看他們會做些什麼，他們是否基於源程式碼開始構建？爲專案增加新的特性？他們將專案用於科研？還是業務？
+
+## 留下來
+
+人們找到了你的專案，而且已經在使用了。那麼接下來你要問自己的問題就是：_人們有對這個專案做貢獻嗎?_
+
+不管什麼時候考慮貢獻者這個問題都不能算早。沒有大眾的參與，你就可能會把自己置於一個尷尬的境地，那就是你的專案雖然很 _流行_（很多人用）但是並不被 _支持_（維護者沒有足夠的時間來滿足用戶的需求）。
+
+保持專案的進展需要[貢獻者的流動](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2)（意思是有進有出）因爲之前很活躍的貢獻者也可能會去幹別的事情。
+
+可能會經常用的衡量社群的指標包括：
+
+* **貢獻者的總數和每個貢獻者的提交次數：** 有多少貢獻者，哪些是活躍的，哪些是不活躍。github上，你可以在"Graphs" -> "Contributors"面板查看這些資訊。目前，這個圖標只計算了那些往倉庫默認分支推送的貢獻者。
+
+
+
+* **第一次，偶爾爲之的，和持續的貢獻者：** 幫助檢測是否有新的貢獻者，以及他們是不是會再來。（偶爾的貢獻者是那些提交的次數很少的人，當然啦，這個數目是多少取決於你，比如說五次。）如果沒有新的貢獻者，你的專案就會停滯不前。
+
+* **打開的issue的數目和PR的數目：** 如果這些數目太高，就意味着你可能需要有人幫你給issue分類以及做代碼審查。
+
+* **所有的打開過的issue和PR：** 一個issue被人提出說明你的專案對他來說比較重要。如果這個數目隨着時間在增長，這就意味着人們對你的專案感興趣。
+
+* **不同種類的貢獻者：** 比如說，提交代碼，修復筆誤或者bug，或者在issue下面評論。
+
+
+
+## 維護者活躍度
+
+最後，你還需要確定一件事，那就是維護者有足夠的能力和時間處理社群的貢獻。最後一個問題你要問自己的是：_我是不是有足夠的時間和精力來回應社群？_
+
+沒有責任心的維護者絕對是開源專案的災難。想象一下就知道，假如一位貢獻者提交了代碼或其他貢獻，但從來沒有得到過維護者的回覆，他 100% 會感到灰心，並最終選擇離開。
+
+[來自Mozilla的研究](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 說： **維護者的回應是鼓勵更多貢獻者中非常重要的一環**。
+
+考慮記錄一下你或者其他的專案維護者對一次貢獻（issue或者PR）回應的時間，回應並不需要花多少精力。哪怕只是說一句："謝謝你的貢獻，我下週會查看的。"
+
+你也可以測量一在一個貢獻被處理的過程中狀態變化的時間。比如：
+
+* 一個issue保持打開狀態的時間（也就代表一個問題保持沒有被解決狀態的時間）。
+* 一個issue是否因爲一個PR得到解決。
+* 陳舊的iuuse是否被關閉了（被解決的問題應該關閉）。
+* 合併一個PR的時間。
+
+## 使用 📊 學習關於人本身
+
+理解一些細節能夠幫助你建設活躍的、成長的開源專案。哪怕是你無法追蹤每一個細節，通過使用上述的框架，將能夠讓你集中精力到該用力的地方，進而助專案成功！
diff --git a/_articles/zh-tw/starting-a-project.md b/_articles/zh-tw/starting-a-project.md
new file mode 100644
index 00000000000..3fd11b0793e
--- /dev/null
+++ b/_articles/zh-tw/starting-a-project.md
@@ -0,0 +1,363 @@
+---
+lang: zh-tw
+title: 發起一個開源專案
+description: 從開源的世界汲取智慧，著手發起開源專案。
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+ - finding
+ - building
+---
+
+## 什麼是開源，爲什麼要開源
+
+所以你在考慮開始參與開源？恭喜！世界讚賞你的貢獻。讓我們來談談開源是什麼，以及人們這樣做。
+
+### "開源"是什麼意思
+
+當一個專案被開源，這意味着**任何人都可以出於任何目的查看，使用，修改和分發你的專案**。 這些權限通過[開源許可](https://opensource.org/licenses)強制實施。
+
+開源是強大的，因爲它降低了事物被採納的障礙，允許想法迅速傳播。
+
+要瞭解它的工作原理，想象你的朋友組織了一場聚餐，而你帶去了一個櫻桃派。
+
+* 每個人都嚐了那個派（_使用_)
+* 派的味道棒極了！大家請你分享它的配方（_view_）
+* 一個叫 Alex 的朋友是個糕點師，他建議少放點糖（_modify_）
+* 一個叫 Lisa 的朋友想要用它作爲下週的晚餐（_distribute_）
+
+相比之下，一個閉源過程就像去一家餐廳訂購一個櫻桃派。你必須爲了吃餅支付費用，餐廳恐怕不會給你他們的食譜。如果你準確地複製了他們的餡餅，並以你自己的名義出售，餐廳可以對你採取措施。
+
+### 人們爲什麼把他們的作品開源？
+
+
+
+個人或組織爲何想要開源一個專案，[有各種各樣的的原因](http://ben.balter.com/2015/11/23/why-open-source/)，例如：
+
+* **協作：** 開源專案可以接受世界各地人們的修改。 例如 [Exercism](https://github.com/exercism/) 就是一個擁有350多個貢獻者的練習平臺。
+
+* **採用和重組：** 任何人幾乎可以出於任何目的使用開源專案。人們甚至可以使用它來構建其他東西。例如，[WordPress](https://github.com/WordPress) 就是派生自一個名爲 [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) 的現有專案。
+
+* **透明度：** 任何人都可以檢查開源專案是否有錯誤或不一致。 透明度對[保加利亞](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美國](https://sourcecode.cio.gov/)等政府，銀行或醫療保健等受監管行業以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全軟件都很重要。
+
+開源並不僅僅限於軟件。您可以開源任何事物，從數據集到書本。查看 [GitHub Explore](https://github.com/explore) 開找找有什麼是你可以開源的。
+
+### 開源是指"免費"嗎
+
+開源最大的吸引之一是它不花錢。 但是，"免費"只是開源的總體價值的一個副產品。
+
+因爲[開源許可證要求](https://opensource.org/osd-annotated)任何人可以幾乎出於任何目使用，修改和共享您的專案，專案本身往往是免費的。 如果該專案花錢使用，任何人也都可以合法地複製和使用免費版本。
+
+因此，大多數開源專案是免費的，但"免費"不是開源定義的一部分。 有些方法可以通過雙重許可或有限功能間接地爲開源專案收費，同時仍然遵守開源的官方定義。
+
+## 我是否應該發起我自己的開源專案
+
+簡單來說，答案是肯定的，因爲無論結果如何，啓動您自己的專案來瞭解開源的工作原理是一個好方法。
+
+如果你從來沒有創建過一個專案，你可能會擔心人們會說什麼，或者是否有人會注意到。 如果這聽起來像你現在的狀態，別擔心，你並不孤獨！
+
+開源工作就像任何其他充滿創意的活動，無論是寫作還是繪畫。 向世界分享你的作品會讓你提心吊膽，但唯有練習能夠讓你的感覺變好的方法 - 即使你沒有觀衆。
+
+如果你還不確信，請花一點時間思考你的目標可能是什麼。
+
+### 設置你的目標
+
+目標可以幫助你弄清該做什麼，不應該說什麼，以及你在哪方面需要其他人的幫助。 首先問自己，_我是爲什麼開源這個專案？_
+
+這個問題沒有標準答案。 對於一個專案你可以有多個目標，或者具有不同目標的不同專案。
+
+如果你唯一的目標是炫耀你的工作，你甚至可能不需要他人的貢獻，甚至在你的 README 中說明這點。但另一方面，如果你需要貢獻者，你會投入時間來使文檔清晰，好讓新的參與者感到歡迎。
+
+
+
+隨着你的專案增長，你的社群可能不僅需要你的代碼。迴應問題，審查代碼和傳播你的專案都會成爲開源專案中的重要任務。
+
+而你在非編碼的任務上花費的時間將取決於專案的大小和範圍，你應該準備好作爲維護者來自己解決或找人幫助你。
+
+**如果你是公司開源專案的一部分，** 確保你的專案有它需要茁壯成長的內部資源。 你需要確定誰在啓動後負責維護專案，以及如何與你的社群共享這些任務。
+
+如果你需要專門的預算或人員來促進，操作和維護專案，請儘早提出。
+
+
+
+### 加入其他專案
+
+如果你的目標是學習如何與他人合作或瞭解開源的工作方式，請考慮爲現有專案做出貢獻。從你已經使用並喜歡的專案開始。像修復拼寫錯誤或更新文檔簡單的事也能爲專案做出貢獻。
+
+如果你不知道如何開始作爲貢獻者，請查看我們的[如何貢獻開源指南](../how-to-contribute/)。
+
+## 發起自己的開源專案
+
+即使你沒有很好的時間來開源你的工作。你也可以開源一個想法，正在進行中的工作，或是關閉了多年的源碼。
+
+一般來說，如果你樂意於他人對你工作的查看和反饋，你就應該開源你的專案。
+
+無論您決定開展專案的哪個階段，每個專案都應包括以下文檔：
+
+* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
+* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Code of conduct](../code-of-conduct/)
+
+作爲維護者，這些組件將幫助你交流你的期望，管理貢獻並保護每個人的合法權益（也包括您自己的）。他們能夠大大增加你積極體驗的機會。
+
+如果您的專案在 GitHub 上，則將這些文件放在您的根目錄中，並使用推薦的文件名將有助於 GitHub 識別並自動將其顯示給讀者。
+
+### 選擇一個許可證 (license)
+
+開源許可證保證其他人可以使用，複製，修改和貢獻給您的專案，而不會產生不良後果。 它也可以保護您免受繁瑣的法律影響。**啓動開源專案時，請務必包含許可證。**
+
+法律工作是非常無趣的。但好消息是，您可以將現有許可證複製並粘貼到存儲庫中。只需要花這麼一點時間，就能保護你的辛苦工作。
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), 和 [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) 都是非常流行的開源許可證， 但你可以選擇[其他選項](https://choosealicense.com).
+
+當你在GitHub上創建新專案時，你可以選擇許可證。包括開源許可證將使你的GitHub專案成爲開源。
+
+
+
+如果您在管理開放源碼專案的法律方面有其他問題或疑慮，我們已經[在這裏](../legal/)介紹了。
+
+### 編寫自述文件
+
+自述文件不僅僅是用於說明如何使用你的專案。他們還可以解釋你的專案爲什麼重要，以及它可以爲你的用戶做什麼。
+
+在您的自述文件中，嘗試回答以下問題：
+
+* 這個專案做什麼？
+* 爲什麼這個專案有用？
+* 如何開始？
+* 如果需要，我可以在哪裏獲得更多的幫助？
+
+您可以使用自己的README回答其他問題，例如處理貢獻，專案的目標以及許可證和歸屬資訊。 如果您不想接受他人的貢獻，或者您的專案尚未準備好作爲產品提供使用，請將這些資訊寫下來。
+
+
+
+有時，人們會因爲覺得專案未完成而不願意撰寫 README，或者他們不希望做出貢獻。這些都是寫一個 README 的很好的理由。
+
+想要獲得更多靈感，請嘗試使用 @18F 的 ["讓 README 可讀"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) 或者 @PurpleBooth 的 [README 模板](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) 來撰寫一個完整的 README。
+
+當你在根目錄中包含一個 README 文件時，GitHub 會自動將其顯示在存儲庫的主頁上。
+
+### 編寫你的貢獻指南
+
+貢獻文件 (CONTRIBUTING file) 告訴你的受衆如何參與你的專案. 例如，你可以包括一下資訊:
+
+* 如何提交錯誤報告（嘗試使用[issue 和 pull request 模板](https://github.com/blog/2111-issue-and-pull-request-templates)）
+* 如何建議一個新功能
+* 如何配置你的環境和運行測試
+
+除了技術細節， 貢獻文件也是一個供你傳達對貢獻期待的機會， 例如：
+
+* 你在尋求的貢獻類型
+* 你專案的路線圖或者版本
+* 貢獻者應該（或者不應該）如何與你取得聯繫
+
+溫柔友好的逾期和向貢獻者們提供具體的建議（例如寫文檔或者搭建一個網頁）能夠有效地使新人感到受歡迎並樂於參與其中。
+
+例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以這樣的方式開始[它的貢獻指南](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md)：
+
+> 首先， 非常感謝你考慮爲 Active Admin 貢獻幫助。正式你這樣的人們使得 Active Admin 成爲瞭如此優秀的工具。
+
+在你專案開始的初期，你的貢獻文件可以很簡單。你應該經常解釋如何提交錯誤和文件問題，以及關於如何作出貢獻的技術問題（例如測試）。
+
+隨着時間的推移，你硬弓增加其他常見問題到你的貢獻文件中去。寫下這些資訊意味着問你相同問題的人會越來越少。
+
+想要獲得更多有關編寫貢獻文件的方式，請查閱 @nayafia 的 [貢獻指南模板](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) 或者 @mozilla 的 ["如何構建 CONTRIBUTION.md"](http://mozillascience.github.io/working-open-workshop/contributing/)。
+
+來你的 README 中鏈接你的 CONTRIBUTING，這樣更多人就能看到他。如果你[在你的專案中放入了 CONTRIBUTING 文件](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)，當一個貢獻者創建 issue 或者開啓一個 pull request 時，GitHub 會自動鏈接你的文件。
+
+
+
+### 建立行爲規範
+
+
+
+最後，行爲規範有助於爲你專案的參與者車裏行爲規則。這在你爲社群或者專案推出一個開源專案的時候尤爲有價值。一份行爲幫助你促進健康，有建設性的社群行爲，這也會減輕你作爲維護者的壓力。
+
+更多資訊，請參見 [行爲規範指導](../code-of-conduct/)。
+
+除了傳達你期待參與者**如何**行動，行爲規範也傾向於描述這些期待針對誰，適用於何時，以及對於違規行爲的處理方法。
+
+就像開源許可證一樣，有現成的行爲規範，所以你不必自己編寫。[貢獻者公約](http://contributor-covenant.org/)是一個行之有效的行爲規範，已經被用在[超過4000個開源專案](http://contributor-covenant.org/adopters/)，包括 Kubernetes，Rails，以及 Swift。無論你使用哪一種，你都應該準備好在必要時執行行爲規範。
+
+將文本直接粘貼到專案存儲庫中的 CODE_OF_CONDUCT 文件中。將文件保存在專案的根目錄中，以便輕鬆找到，並從 README 中鏈接到它。
+
+## 爲專案命名及設立品牌
+
+品牌不僅是一個華麗的logo或者易記的專案名。它還關於你如何談論你的專案，以及你想把資訊傳遞給誰。
+
+### 選擇正確的名字
+
+選擇一個容易記住，有創意，能表達專案用意的名字。例如：
+
+* [Sentry](https://github.com/getsentry/sentry) 監控應用程序的崩潰報告
+* [Thin](https://github.com/macournoyer/thin) 是一個簡單快速的Ruby web服務器。
+
+如果你的專案是基於一個已存在的專案創建，那麼使用他們的名字作爲你專案名的前綴會幫助你闡述你專案的用途。 (例如 [node-fetch](https://github.com/bitinn/node-fetch)將`window.fetch` 添加到了 Node.js)。
+
+考慮闡明所有。押韻雖然有趣，但是記住玩笑不可能轉變成其它的文化，或者他人與你有不同的經歷。你的一些潛在用戶可能是公司員工，你不能讓他們在工作中很難解釋你的專案！
+
+### 避免命名衝突
+
+[查看是否有同名的開源專案](http://ivantomic.com/projects/ospnc/)，尤其是你分享的是同樣的語言或者生態系統。如果你的名字與一個已存在的知名的專案有衝突，你會讓你的粉絲感到困惑。
+
+如果你想要一個網站，Twitter賬號或者其他特性來展示你的專案，先確保你能得到你想要的名字。理想情況下，爲了美好的未來[現在保留這些名字](https://instantdomainsearch.com/)，即使你現在不想用他們。
+
+確保你的專案名沒有侵權。如果有侵權，可能會有公司要求你的專案下架，或者對你採取法律措施。這樣得不償失。
+
+ 你可以查閱[WIPO全球品牌數據庫](http://www.wipo.int/branddb/en/)避免商標衝突。如果你是在公司工作，[法律團隊會幫你做這件事](../legal/)。
+
+最後，去谷歌搜索你的專案名。大家會很容易地找到你的專案嗎？在搜索結果禮是否有你不想讓大家看到的東西？
+
+### 你的寫作（和代碼）如何影響你的品牌
+
+在專案的整個生命週期中，你需要做很多文字工作：READMEs，教程，社群文檔，回覆issues，甚至肯能要處理很多來信和郵件。
+
+是否是官方文檔或者一封普通的郵件，你的書寫風格都是你專案品牌的一部分。考慮你可能會擁有粉絲，以及這是你想傳達的聲音。
+
+
+
+使用熱情，通俗易懂的語言（如"他們"，即使是指一個人）能夠讓新來的貢獻者感覺專案非常歡迎他們。使用簡單的語言，因爲你的讀者可能英語不是很好。
+
+除了書寫風格外，你的編碼風格也是你專案品牌的一部分。 [Angular](https://github.com/johnpapa/angular-styleguide) 和 [jQuery](http://contribute.jquery.org/style-guide/js/)是兩個專案代碼風格嚴謹的示例和指南。
+
+當你的專案纔開始時，沒有必要爲專案編寫一份風格指南。你可能會發現你喜歡將不同的編碼風格融入到專案。但是你應該想到你的書寫和編碼風格會吸引或者拒絕不同類型的人。專案的早期是你建立你希望看見的先例的機會。
+
+## 發起專案之前的檢查項
+
+準備好開源你的專案了嗎？有一份幫助檢查清單。檢查所有內容？你準備開始吧！ [點擊 "publish"](https://help.github.com/articles/making-a-private-repository-public/) 以及拍下自己的後背。
+
+**文檔**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**代碼**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**人**
+
+如果你是代表個人：
+
+
+
+
+
+
+如果你有一家公司或者組織：
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## 你做到了
+
+恭喜你開源了你的首個專案。不論結果如何，對開源社群都是一份禮物。隨着每次commit,comment和pull request，你正在爲自己或者他人創造學習和成長的機會。
diff --git a/_data/locales/zh-tw.yml b/_data/locales/zh-tw.yml
new file mode 100644
index 00000000000..52b153ab24f
--- /dev/null
+++ b/_data/locales/zh-tw.yml
@@ -0,0 +1,31 @@
+zh-tw:
+ locale_name: 繁體中文
+ nav:
+ about: 關於
+ contribute: 貢獻
+ index:
+ lead: 開放原始碼就是由你這樣的人所打造，學習如何發起、經營你的開源專案！
+ opensourcefriday: 今天是星期五！ 花一些時間去貢獻你使用過、喜愛的軟體吧！
+ article:
+ table_of_contents: 目錄
+ back_to_all_guides: 回到所有指南
+ related_guides: 相關指南
+ footer:
+ contribute:
+ heading: 貢獻
+ description: 想提出建議嗎？本站是開放原始碼，協助我們更加完善。
+ button: 貢獻
+ subscribe:
+ heading: 訂閱最新消息
+ description: 即時了解GitHub最新的開源技巧和資源！
+ label: 電子信箱地址
+ button: 訂閱
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] with [love] by [github]"
+ # Label for code octicon
+ code_label: 程式
+ # Label for love octicon
+ love_label: 愛心
+ # Label for the contributors link
+ friends_label: 協作朋友