Fix internal external link

Signed-off-by: Samuel Jiang <[email protected]>

Author: jyangchisyan

_articles/zh-tw/best-practices.md

@@ -162,7 +162,7 @@ related:
 
 當你看到新的貢獻者不停的提交貢獻，通過分配給他們更多任務來表示認可。如果別人願意的話，記錄下別人是怎麼成長爲領導者的過程。
 
-鼓勵別人來[一起管理專案](../building-community/#share-ownership-of-your-project)能很大程度上減輕你的工作量，就像 [@lmccart](https://github.com/lmccart) 在他的專案上做的那樣，[p5.js](https://github.com/processing/p5.js)
+鼓勵別人來[一起管理專案](../building-community/#分享專案的所有權)能很大程度上減輕你的工作量，就像 [@lmccart](https://github.com/lmccart) 在他的專案上做的那樣，[p5.js](https://github.com/processing/p5.js)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">

_articles/zh-tw/building-community.md

@@ -33,8 +33,8 @@ related:
 
 * **當有人選擇了你們的專案，記得對他們表示謝意！** 因為可能只是一次不愉快的經歷，就足以讓一些人再也不想回來。
 * **及時回應。** 如果一個月都沒有回答他們的 issue，他們可能也早就忘記了你們的專案。
-* **以開放的態度接受各式各樣的貢獻。** 很多貢獻者是從提報一份 bug 或者修一些小東西開始的。這裡有[很多為專案做貢獻的方式](../how-to-contribute/#what-it-means-to-contribute)。讓大家選擇他們喜歡的方式。
-* **如果你不贊成一個貢獻。** 首先你需要對他們的想法表示感謝，同時 [解釋為什麼](../best-practices/#learning-to-say-no)這點子不適合專案，如果有必要的話你可以給出相關文件的連結。
+* **以開放的態度接受各式各樣的貢獻。** 很多貢獻者是從提報一份 bug 或者修一些小東西開始的。這裡有[很多為專案做貢獻的方式](../how-to-contribute/#具體而言什麼是貢獻)。讓大家選擇他們喜歡的方式。
+* **如果你不贊成一個貢獻。** 首先你需要對他們的想法表示感謝，同時 [解釋為什麼](../best-practices/#學會拒絕他人)這點子不適合專案，如果有必要的話你可以給出相關文件的連結。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
@@ -123,7 +123,7 @@ related:
 
 對專案的顯而易見的問題進行定期辯論，會分散別人的注意力，包括你自己，新人如果看見這樣的情景，他們可能不會加入到專案中來。記得要將精力放在重要的任務上。
 
-當發現社群中有負面的行為時，要即時、公開的指出來。要用堅定的語氣解釋他們的行為為什麼是不可接受的。如果問題持續發生，你有必要[請他們離開](../code-of-conduct/#enforcing-your-code-of-conduct)。你的[行為準則](../code-of-conduct/)是為這些情境準備的建設性指南。
+當發現社群中有負面的行為時，要即時、公開的指出來。要用堅定的語氣解釋他們的行為為什麼是不可接受的。如果問題持續發生，你有必要 [請他們離開](../code-of-conduct/#蒐集有關違規的資訊) 。你的 [行為準則](../code-of-conduct/) 是為這些情境準備的建設性指南。
 
 ### 知道貢獻者在哪裡
 
@@ -210,7 +210,7 @@ related:
 
 ### 視 README 為最高原則
 
-README [不僅僅是指導手冊](../starting-a-project/#writing-a-readme)。它也是一個談論目標、願景和路線的地方。
+README [不僅僅是指導手冊](../starting-a-project/#編寫自述文件)。它也是一個談論目標、願景和路線的地方。
 如果人們放太多精力在討論特定功能的優點，這時重新審視 README 並討論遠景也許會比較有幫助。關注 README 也能讓大家就事論事的去討論，讓對話變得有建設性的。
 
 ### 專注過程，而不是結果

_articles/zh-tw/code-of-conduct.md

@@ -24,7 +24,7 @@ related:
 
 此外，說出你們的要求。行爲守則的描述遵循如下幾點：
 
-* 行爲守則在哪裏有效 _(只在issues以及pull requests，或者社群活動？)_  
+* 行爲守則在哪裏有效 _(只在issues以及pull requests，或者社群活動？)_
 * 行爲守則適用於誰 _(社群成員以及維護者，那贊助商呢？)_
 * 如果有人違反了行爲守則會怎樣？
 * 大家如何舉報違規

_articles/zh-tw/finding-users.md

@@ -135,7 +135,7 @@ related:
   <img src="https://avatars2.githubusercontent.com/u/6292?v=3&s=400" class="pquote-avatar" alt="avatar">
   urllib3之所以成為最流行的Python第三方庫的唯一原因就是大家都需要他。
   <p markdown="1" class="pquote-credit">
-— @shazow, ["How to make your open source project thrive"](https://text.sourcegraph.com/how-to-make-your-open-source-project-thrive-with-andrey-petrov-6463b935c540#.mk31f8fgf)
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov)
   </p>
 </aside>
 

_articles/zh-tw/how-to-contribute.md

@@ -48,7 +48,7 @@ related:
 
 你不一定要持續不斷的貢獻開源才能享受參與的樂趣。你是否曾在某個網站上發現拼寫錯誤，並希望有人能夠修改它？在開源專案中你可以親自修正這樣的錯誤即可。開源讓人們自在的做事，而這正是這個世界應有的體驗。
 
-## **具體而言什麼是貢獻**
+## 具體而言什麼是貢獻
 
 如果你是一名開源世界的新手，可能會對貢獻的流程心生畏懼。如何找到適合彼此的專案？不會寫程式又想參與怎麼辦？萬一中間出了差錯怎麼辦？
 
@@ -449,7 +449,7 @@ related:
   </p>
 </aside>
 
-### **創建 issue**
+### 提出問題
 
 你應該在遇到下列情況時，去創建一個 issue：
 
@@ -491,7 +491,7 @@ related:
 
 ### 😭 **沒有人理你。**
 
-希望你在工作開始之前[檢查過了專案的活躍度](#a-checklist-before-you-contribute)，不過有時即使檢查過了，在一個活躍的專案中沒有人理會你的貢獻也是很正常的。
+希望你在工作開始之前[檢查過了專案的活躍度](./#提出問題)，不過有時即使檢查過了，在一個活躍的專案中沒有人理會你的貢獻也是很正常的。
 
 如果過了一週，依舊沒有人回應，請心平氣和的在同個條目下留言，請人幫你審核。如果你知道可以找誰審核，你可以使用 @名字，提醒他一下。
 

_articles/zh-tw/leadership-and-governance.md

@@ -40,7 +40,7 @@ related:
 
 **術語 "修訂者"** 可能用於區分其他形式的貢獻的提交訪問，這是一種特定類型的責任。
 
-其實你可以根據自己喜歡的方式來定義專案的角色，[考慮使用更廣泛的定義](../how-to-contribute/#what-it-means-to-contribute) 來鼓勵更多的形式的貢獻。無論技術技能如何，您都可以使用領導角色來正式識別爲您的專案做出突出貢獻的人員。
+其實你可以根據自己喜歡的方式來定義專案的角色，[考慮使用更廣泛的定義](../how-to-contribute/#具體而言什麼是貢獻) 來鼓勵更多的形式的貢獻。無論技術技能如何，您都可以使用領導角色來正式識別爲您的專案做出突出貢獻的人員。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars3.githubusercontent.com/u/21148?v=3&s=460" class="pquote-avatar" alt="avatar">
@@ -75,7 +75,7 @@ related:
 諸如[Vossibility](https://github.com/icecrime/vossibility-stack) 這樣的工具，可以幫助你追蹤誰是（或不是）專案的貢獻者。爲這些資訊作說明，以避免社群出現維護者作出私自的決定。
 
 另外，如果你的專案在託管在GitHub上，考慮將你的專案從個人賬戶遷移到某個組織，而且要爲組織增加額外的一個備份的管理員。
-[GitHub 上的組織](https://help.github.com/articles/creating-a-new-organization-account/) 能夠讓權限管理和多倉庫管理更加的輕鬆，而且可通過 [共享所有權](../building-community/#share-ownership-of-your-project)來保護你的專案。
+[GitHub 上的組織](https://help.github.com/articles/creating-a-new-organization-account/) 能夠讓權限管理和多倉庫管理更加的輕鬆，而且可通過 [共享所有權](../building-community/#分享專案的所有權)來保護你的專案。
 
 ## 何時該賦予提交者權限？
 

_articles/zh-tw/legal.md

@@ -68,9 +68,9 @@ related:
 * **你們的專案是否想吸引大企業？**大型企業可能需要所有貢獻者的明確專利許可。在這種情況下，[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許可協議同時要求貢獻者贊成，這樣專案只屬於你們公司，沒有人能在有關的軟件中使用你們的專案。或者你們的公司可能有與標準，社會責任或透明度相關的某些需求，其中任何一個都可能需要特定的許可策略。與你們[公司的法律部門](#我的公司的法律團隊需要知道什麼？)談談。
+你們的公司可能爲自己的專案準備了特定的許可協議。例如，它可能需要許可許可證，以便公司可以在公司的閉源產品中使用你們的專案。或者你們的公司要求強大的copyleft許可協議同時要求貢獻者贊成，這樣專案只屬於你們公司，沒有人能在有關的軟件中使用你們的專案。或者你們的公司可能有與標準，社會責任或透明度相關的某些需求，其中任何一個都可能需要特定的許可策略。與你們[公司的法律部門](#公司的法律團隊需要知道什麼)談談。
 
-當你們在GitHub上創建了一個新專案，它給你們提供了選擇許可協議的機會。包括上面提到的可以使你們的GitHub專案開源的許可協議。如果你們想要瞭解其他選擇，可以通過查閱[choosealicense.com](https://choosealicense.com)找到適合你們專案（即使它[不是軟件](https://choosealicense.com/non-software/)）的許可協議。
+當你們在GitHub上創建了一個新專案，它給你們提供了選擇許可協議的機會。包括上面提到的可以使你們的GitHub專案開源的許可協議。如果你們想要瞭解其他選擇，可以通過查閱[choosealicense.com](https://choosealicense.com)找到適合你們專案（即使它[不是軟體](https://choosealicense.com/non-software/)）的許可協議。
 
 ## 如果我想更換專案的許可協議，該怎麼辦？
 
@@ -111,7 +111,7 @@ related:
 
 如果您們實需要在您的專案中使用額外的貢獻者協議，請考慮使用諸如CLA助手之類的集成，以最大限度地減少貢獻者的分心。
 
-## 我的公司的法律團隊需要知道什麼？
+## 公司的法律團隊需要知道什麼
 
 作爲一名公司的僱員，如果你們在發佈一個開源專案，你們首先需要讓法律團隊知道。
 即使只是一個個人專案，請考慮讓他們知道。你們可能和公司有一個"員工知識產權協議"，這給了公司一些對你們專案的控制權，特別是當專案和公司的業務有著很多的聯繫或者你們使用公司的資源發展專案。你們的公司_應該_很容易給們許可，也許已經通過一個員工友好的知識產權協議或公司政策。如果不是這樣，你麼可以談判（例如，解釋你們的專案爲公司的專業學習和發展目標服務），或者你們在找到一個更好的公司前停止你們專案的工作。
@@ -143,7 +143,7 @@ related:
 </aside>
 
 * **發佈什麼：**[（幾乎） 所有？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)如果你們的法律團隊瞭解並投資於你們公司的開源策略，他們將是你們最好的幫助，而不是阻礙你們的努力。
-* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program)可以避免麻煩，產品延遲發佈和訴訟。
+* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。
 
 <aside markdown="1" class="pquote">
   組織必須具有適合["允許"和"copyleft"]類別的許可協議和合規性策略。首先，記錄適用於你們所使用的開源軟件的許可條款（包括子組件和依賴項）。

_articles/zh-tw/starting-a-project.md

@@ -35,7 +35,7 @@ related:
   <img src="https://avatars1.githubusercontent.com/u/1500684?v=3&s=460" class="pquote-avatar" alt="avatar">
 我從開源使用和協作中獲得的最有價值的經驗之一，就是在我面臨許多與其他開發人員相同問題的過程中所建立的聯繫。
   <p markdown="1" class="pquote-credit">
-    — @kentcdodds, ["參與開源對我來說太棒了"](https://medium.com/@kentcdodds/how-getting-into-open-source-has-been-awesome-for-me-8480cd756a80#.pjt9oqp4w)
+    — @kentcdodds, ["參與開源對我來說太棒了"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
   </p>
 </aside>
 
@@ -77,9 +77,9 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars2.githubusercontent.com/u/3520168?v=3&s=460" class="pquote-avatar" alt="avatar">
-在某些時候，我創建了一個自己正在使用的自定義 UIAlertView，我決定將它開源。所以我修改它使其更有活力，並把它上傳到了 GitHub。我還寫了我的第一個文檔，解釋給其他開發人員如何在他們的專案中使用它。很可能沒有人會去使用它，因爲它是一個簡單的專案，但我的貢獻讓我感覺很好。 
+在某些時候，我創建了一個自己正在使用的自定義 UIAlertView，我決定將它開源。所以我修改它使其更有活力，並把它上傳到了 GitHub。我還寫了我的第一個文檔，解釋給其他開發人員如何在他們的專案中使用它。很可能沒有人會去使用它，因爲它是一個簡單的專案，但我的貢獻讓我感覺很好。
   <p markdown="1" class="pquote-credit">
-— @mavris, ["自學的軟件開發者：爲什麼開源對我們那麼重要"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576#.zhwo5krlq)
+— @mavris, ["自學的軟件開發者：爲什麼開源對我們那麼重要"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
   </p>
 </aside>
 
@@ -95,7 +95,7 @@ related:
   <img src="https://avatars2.githubusercontent.com/u/1857993?v=3&s=460" class="pquote-avatar" alt="avatar">
 當你開始開源一個專案時，確保您的管理流程考慮到您專案周圍社群的貢獻和能力很重要。不要害怕讓那些沒有在你的企業中受僱的貢獻者參與專案的關鍵部分 - 尤其如果他們是頻繁的貢獻者的話。
   <p markdown="1" class="pquote-credit">
-— @captainsafia, ["所以你想開源一個專案，是嗎？"](https://writing.safia.rocks/2016/12/06/so-you-wanna-open-source-a-project-eh/)
+— @captainsafia, ["所以你想開源一個專案，是嗎？"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
   </p>
 </aside>
 
@@ -136,7 +136,7 @@ related:
 
 如果您在管理開放源碼專案的法律方面有其他問題或疑慮，我們已經[在這裏](../legal/)介紹了。
 
-### 編寫自述文件 (README)
+### 編寫自述文件
 
 自述文件不僅僅是用於說明如何使用你的專案。他們還可以解釋你的專案爲什麼重要，以及它可以爲你的用戶做什麼。
 
@@ -153,7 +153,7 @@ related:
   <img src="https://avatars0.githubusercontent.com/u/168572?v=3&s=460" class="pquote-avatar" alt="avatar">
 更好的文檔意味着更多的用戶，更少的求助和更多的貢獻者，等等。要記住你的讀者不是你自己。來到專案中的每個人可能有着截然不同的經歷。
   <p markdown="1" class="pquote-credit">
-— @limedaring, ["這樣寫給他人看（視頻）"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+— @tracymakes, ["這樣寫給他人看（視頻）"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
   </p>
 </aside>