From 025bab46eb8da29d2162ceca2010600b8c804fee Mon Sep 17 00:00:00 2001
From: Brian <mookwoo84@gmail.com>
Date: Sat, 4 Apr 2026 15:23:53 -0400
Subject: [PATCH 1/2] Replace outdated help.github.com URLs with
 docs.github.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All references to help.github.com (which redirects to docs.github.com)
have been updated to point directly to the current docs.github.com URLs.
This covers all 12 English articles, 27 translation directories, and
the docs/ folder.

URL mappings applied:
- help.github.com/articles/about-repository-graphs/#traffic
- help.github.com/articles/about-stars/
- help.github.com/articles/about-protected-branches/
- help.github.com/articles/about-required-status-checks/
- help.github.com/articles/syncing-a-fork/
- help.github.com/articles/watching-repositories/
- help.github.com/articles/creating-a-new-repository/
- help.github.com/articles/creating-a-new-organization-account/
- help.github.com/articles/open-source-licensing/
- help.github.com/articles/create-a-repo/#commit-your-first-change
- help.github.com/articles/setting-guidelines-for-repository-contributors/
- help.github.com/articles/making-a-private-repository-public/
- help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels
- help.github.com/en/github/site-policy/github-terms-of-service
- help.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository
- help.github.com → docs.github.com (content-model.md)
- guides.github.com → skills.github.com (content-model.md)
---
 _articles/ar/building-community.md             |  4 ++--
 _articles/ar/how-to-contribute.md              |  4 ++--
 _articles/ar/leadership-and-governance.md      |  4 ++--
 _articles/ar/legal.md                          |  6 +++---
 _articles/ar/metrics.md                        |  4 ++--
 _articles/ar/starting-a-project.md             | 10 +++++-----
 _articles/best-practices.md                    |  4 ++--
 _articles/bg/best-practices.md                 |  2 +-
 _articles/bg/building-community.md             |  4 ++--
 _articles/bg/how-to-contribute.md              |  4 ++--
 _articles/bg/leadership-and-governance.md      |  4 ++--
 _articles/bg/legal.md                          |  6 +++---
 _articles/bg/metrics.md                        |  4 ++--
 _articles/bg/starting-a-project.md             | 10 +++++-----
 _articles/bn/best-practices.md                 |  4 ++--
 _articles/bn/building-community.md             |  4 ++--
 _articles/bn/how-to-contribute.md              |  4 ++--
 _articles/bn/leadership-and-governance.md      |  4 ++--
 _articles/bn/legal.md                          |  6 +++---
 _articles/bn/metrics.md                        |  4 ++--
 _articles/bn/starting-a-project.md             | 10 +++++-----
 _articles/building-community.md                |  4 ++--
 _articles/de/best-practices.md                 |  4 ++--
 _articles/de/building-community.md             |  4 ++--
 _articles/de/how-to-contribute.md              |  4 ++--
 _articles/de/leadership-and-governance.md      |  4 ++--
 _articles/de/legal.md                          |  6 +++---
 _articles/de/metrics.md                        |  4 ++--
 _articles/de/starting-a-project.md             | 10 +++++-----
 _articles/el/best-practices.md                 |  4 ++--
 _articles/el/building-community.md             |  4 ++--
 _articles/el/how-to-contribute.md              |  4 ++--
 _articles/el/leadership-and-governance.md      |  4 ++--
 _articles/el/legal.md                          |  6 +++---
 _articles/el/metrics.md                        |  4 ++--
 _articles/el/starting-a-project.md             | 10 +++++-----
 _articles/es/best-practices.md                 |  2 +-
 _articles/es/building-community.md             |  2 +-
 _articles/es/how-to-contribute.md              |  4 ++--
 _articles/es/leadership-and-governance.md      |  4 ++--
 _articles/es/legal.md                          |  6 +++---
 _articles/es/metrics.md                        |  4 ++--
 _articles/es/starting-a-project.md             | 10 +++++-----
 _articles/fa/best-practices.md                 |  4 ++--
 _articles/fa/building-community.md             |  4 ++--
 _articles/fa/how-to-contribute.md              |  4 ++--
 _articles/fa/leadership-and-governance.md      |  4 ++--
 _articles/fa/legal.md                          |  6 +++---
 _articles/fa/metrics.md                        |  4 ++--
 _articles/fa/starting-a-project.md             | 10 +++++-----
 _articles/fr/best-practices.md                 |  2 +-
 _articles/fr/building-community.md             |  2 +-
 _articles/fr/how-to-contribute.md              |  4 ++--
 _articles/fr/leadership-and-governance.md      |  4 ++--
 _articles/fr/legal.md                          |  6 +++---
 _articles/fr/metrics.md                        |  4 ++--
 _articles/fr/starting-a-project.md             | 10 +++++-----
 _articles/hi/best-practices.md                 |  4 ++--
 _articles/hi/building-community.md             |  4 ++--
 _articles/hi/how-to-contribute.md              |  4 ++--
 _articles/hi/leadership-and-governance.md      |  4 ++--
 _articles/hi/legal.md                          |  6 +++---
 _articles/hi/metrics.md                        |  4 ++--
 _articles/hi/starting-a-project.md             | 10 +++++-----
 _articles/how-to-contribute.md                 |  4 ++--
 _articles/hu/best-practices.md                 |  4 ++--
 _articles/hu/building-community.md             |  4 ++--
 _articles/hu/how-to-contribute.md              |  4 ++--
 _articles/hu/leadership-and-governance.md      |  4 ++--
 _articles/hu/legal.md                          |  6 +++---
 _articles/hu/metrics.md                        |  4 ++--
 _articles/hu/starting-a-project.md             | 10 +++++-----
 _articles/id/best-practices.md                 |  2 +-
 _articles/id/building-community.md             |  2 +-
 _articles/id/how-to-contribute.md              |  4 ++--
 _articles/id/leadership-and-governance.md      |  4 ++--
 _articles/id/legal.md                          |  6 +++---
 _articles/id/metrics.md                        |  4 ++--
 _articles/id/starting-a-project.md             | 10 +++++-----
 _articles/it/best-practices.md                 |  2 +-
 _articles/it/building-community.md             |  4 ++--
 _articles/it/how-to-contribute.md              |  4 ++--
 _articles/it/leadership-and-governance.md      |  4 ++--
 _articles/it/legal.md                          |  6 +++---
 _articles/it/metrics.md                        |  4 ++--
 _articles/it/starting-a-project.md             | 10 +++++-----
 _articles/ja/best-practices.md                 |  2 +-
 _articles/ja/building-community.md             |  2 +-
 _articles/ja/how-to-contribute.md              |  4 ++--
 _articles/ja/leadership-and-governance.md      |  4 ++--
 _articles/ja/legal.md                          |  6 +++---
 _articles/ja/metrics.md                        |  4 ++--
 _articles/ja/starting-a-project.md             | 10 +++++-----
 _articles/ko/best-practices.md                 |  2 +-
 _articles/ko/building-community.md             |  2 +-
 _articles/ko/how-to-contribute.md              |  4 ++--
 _articles/ko/leadership-and-governance.md      |  4 ++--
 _articles/ko/legal.md                          |  6 +++---
 _articles/ko/metrics.md                        |  2 +-
 _articles/ko/starting-a-project.md             | 10 +++++-----
 _articles/leadership-and-governance.md         |  4 ++--
 _articles/legal.md                             |  6 +++---
 _articles/metrics.md                           |  4 ++--
 _articles/ms/best-practices.md                 |  4 ++--
 _articles/ms/building-community.md             |  4 ++--
 _articles/ms/how-to-contribute.md              |  4 ++--
 _articles/ms/leadership-and-governance.md      |  4 ++--
 _articles/ms/legal.md                          |  6 +++---
 _articles/ms/metrics.md                        |  4 ++--
 _articles/ms/starting-a-project.md             | 10 +++++-----
 _articles/nl/best-practices.md                 |  4 ++--
 _articles/nl/building-community.md             |  4 ++--
 _articles/nl/how-to-contribute.md              |  4 ++--
 _articles/nl/leadership-and-governance.md      |  4 ++--
 _articles/nl/legal.md                          |  6 +++---
 _articles/nl/metrics.md                        |  4 ++--
 _articles/nl/starting-a-project.md             | 10 +++++-----
 _articles/pcm/best-practices.md                |  4 ++--
 _articles/pcm/building-community.md            |  4 ++--
 _articles/pcm/how-to-contribute.md             |  4 ++--
 _articles/pcm/leadership-and-governance.md     |  4 ++--
 _articles/pcm/legal.md                         |  6 +++---
 _articles/pcm/metrics.md                       |  4 ++--
 _articles/pcm/starting-a-project.md            | 10 +++++-----
 _articles/pl/best-practices.md                 |  4 ++--
 _articles/pl/building-community.md             |  4 ++--
 _articles/pl/how-to-contribute.md              |  4 ++--
 _articles/pl/leadership-and-governance.md      |  4 ++--
 _articles/pl/legal.md                          |  8 ++++----
 _articles/pl/metrics.md                        |  4 ++--
 _articles/pl/starting-a-project.md             | 10 +++++-----
 _articles/pt/best-practices.md                 |  2 +-
 _articles/pt/building-community.md             |  2 +-
 _articles/pt/how-to-contribute.md              |  4 ++--
 _articles/pt/leadership-and-governance.md      |  4 ++--
 _articles/pt/legal.md                          |  6 +++---
 _articles/pt/metrics.md                        |  4 ++--
 _articles/pt/starting-a-project.md             | 10 +++++-----
 _articles/ro/best-practices.md                 |  2 +-
 _articles/ro/building-community.md             |  2 +-
 _articles/ro/how-to-contribute.md              |  4 ++--
 _articles/ro/leadership-and-governance.md      |  4 ++--
 _articles/ro/legal.md                          |  6 +++---
 _articles/ro/metrics.md                        |  4 ++--
 _articles/ro/starting-a-project.md             | 10 +++++-----
 _articles/ru/best-practices.md                 |  4 ++--
 _articles/ru/building-community.md             |  4 ++--
 _articles/ru/how-to-contribute.md              |  4 ++--
 _articles/ru/leadership-and-governance.md      |  4 ++--
 _articles/ru/legal.md                          |  8 ++++----
 _articles/ru/metrics.md                        |  4 ++--
 _articles/ru/starting-a-project.md             | 10 +++++-----
 _articles/sa/best-practices.md                 |  2 +-
 _articles/starting-a-project.md                | 10 +++++-----
 _articles/sw/best-practices.md                 |  4 ++--
 _articles/sw/building-community.md             |  4 ++--
 _articles/sw/how-to-contribute.md              |  4 ++--
 _articles/sw/leadership-and-governance.md      |  4 ++--
 _articles/sw/legal.md                          |  6 +++---
 _articles/sw/metrics.md                        |  4 ++--
 _articles/sw/starting-a-project.md             | 10 +++++-----
 _articles/ta/best-practices.md                 |  2 +-
 _articles/ta/building-community.md             |  2 +-
 _articles/ta/how-to-contribute.md              |  4 ++--
 _articles/ta/leadership-and-governance.md      |  4 ++--
 _articles/ta/legal.md                          |  6 +++---
 _articles/ta/metrics.md                        |  4 ++--
 _articles/ta/starting-a-project.md             | 10 +++++-----
 _articles/tr/best-practices.md                 |  4 ++--
 _articles/tr/building-community.md             |  4 ++--
 _articles/tr/how-to-contribute.md              |  4 ++--
 _articles/tr/leadership-and-governance.md      |  4 ++--
 _articles/tr/legal.md                          |  6 +++---
 _articles/tr/metrics.md                        |  4 ++--
 _articles/tr/starting-a-project.md             | 10 +++++-----
 _articles/zh-hans/how-to-contribute.md         |  4 ++--
 _articles/zh-hans/leadership-and-governance.md |  4 ++--
 _articles/zh-hans/legal.md                     |  4 ++--
 _articles/zh-hans/metrics.md                   |  4 ++--
 _articles/zh-hans/starting-a-project.md        | 10 +++++-----
 _articles/zh-hant/building-community.md        |  2 +-
 _articles/zh-hant/how-to-contribute.md         |  4 ++--
 _articles/zh-hant/leadership-and-governance.md |  4 ++--
 _articles/zh-hant/legal.md                     |  4 ++--
 _articles/zh-hant/metrics.md                   |  4 ++--
 _articles/zh-hant/starting-a-project.md        | 10 +++++-----
 docs/content-model.md                          |  4 ++--
 docs/translations.md                           |  2 +-
 188 files changed, 462 insertions(+), 462 deletions(-)

diff --git a/_articles/ar/building-community.md b/_articles/ar/building-community.md
index 4c2dcb5b026..afee90cf710 100644
--- a/_articles/ar/building-community.md
+++ b/_articles/ar/building-community.md
@@ -30,7 +30,7 @@ related:
 
 * **سهّل على أي شخص استخدام المشروع .** [ملف README سهل الاستخدام](../starting-a-project/#كتابة-ملف-README) وأمثلة كود واضحة تجعل من السهل على أي شخص يزور مشروعك أن يبدأ بسرعة.
 * **اشرح بوضوح كيفية المساهمة،** استخدم [ملف CONTRIBUTING الخاص بك](../starting-a-project/#كتابة-ارشادات-المساهمة-الخاصة-بك) وحافظ على تحديث الـ issues باستمرار.
-* **مهام أولية سهلة للمساهمين الجدد**: لمساعدة المساهمين الجدد على البدء، ضع تسميات واضحة على الـ issues التي يمكن للمبتدئين التعامل معها بسهولة ([وضع labels على الـ issues التي تكون بسيطة بما يكفي ليستطيع المبتدئون التعامل معها.](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels)). سيعرض GitHub هذه الـ issues في أماكن مختلفة على المنصة، مما يزيد المساهمات المفيدة ويقلل من friction عند التعامل مع مشاكل صعبة جدًا لمستوى المستخدم.
+* **مهام أولية سهلة للمساهمين الجدد**: لمساعدة المساهمين الجدد على البدء، ضع تسميات واضحة على الـ issues التي يمكن للمبتدئين التعامل معها بسهولة ([وضع labels على الـ issues التي تكون بسيطة بما يكفي ليستطيع المبتدئون التعامل معها.](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels)). سيعرض GitHub هذه الـ issues في أماكن مختلفة على المنصة، مما يزيد المساهمات المفيدة ويقلل من friction عند التعامل مع مشاكل صعبة جدًا لمستوى المستخدم.
 
 [استطلاع GitHub 2017 عن الـ Open Source](http://opensourcesurvey.org/2017/) أظهر أن الوثائق غير المكتملة أو المربكة هي أكبر مشكلة تواجه مستخدمي الـ open source. توثيق جيد يدعو الناس للتفاعل مع مشروعك. في النهاية، سيقوم شخص ما بفتح issue أو pull request. استخدم هذه التفاعلات كفرص لتحريكهم إلى أسفل القمع (funnel).
 
@@ -169,7 +169,7 @@ related:
 
 * **امنح كل مساهم صلاحية commit.** وجد @felixge أن هذا جعل الناس [أكثر حماسًا لتحسين التعديلات الخاصة بهم](https://felixge.de/2013/03/11/the-pull-request-hack.html)، وحتى وجد مساهمين جدد لمشاريع لم يعمل عليها منذ فترة.
 
-* إذا كان مشروعك على GitHub، **انقل مشروعك من حسابك الشخصي إلى [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** وأضف على الأقل مشرفًا احتياطيًا واحدًا. الـ Organizations تسهل العمل على المشاريع مع مساهمين خارجيين.
+* إذا كان مشروعك على GitHub، **انقل مشروعك من حسابك الشخصي إلى [Organization](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** وأضف على الأقل مشرفًا احتياطيًا واحدًا. الـ Organizations تسهل العمل على المشاريع مع مساهمين خارجيين.
 
 الواقع هو أن [معظم المشاريع](https://peerj.com/preprints/1233/) لديها مشرف أو مشرفان يقومان بمعظم العمل. كلما كان مشروعك ومجتمعك أكبر، كان العثور على المساعدة أسهل.
 
diff --git a/_articles/ar/how-to-contribute.md b/_articles/ar/how-to-contribute.md
index 020229fba39..f7e87866a4e 100644
--- a/_articles/ar/how-to-contribute.md
+++ b/_articles/ar/how-to-contribute.md
@@ -456,7 +456,7 @@ related:
 
 قبل أن تفتح issue أو pull request، تحقق من مستندات المساهمة في المشروع (عادةً ملف يسمى CONTRIBUTING، أو في README)، لتعرف ما إذا كنت بحاجة لتضمين أي شيء محدد. على سبيل المثال، قد يطلبون منك اتباع قالب معين، أو يشترطون أن تستخدم الاختبارات.
 
-إذا كنت تريد تقديم مساهمة كبيرة، افتح issue للسؤال قبل البدء بالعمل عليها. من المفيد متابعة المشروع لفترة (على GitHub، [يمكنك الضغط على "Watch"](https://help.github.com/articles/watching-repositories/) لتصلك إشعارات بكل النقاشات)، والتعرف على أعضاء المجتمع، قبل القيام بعمل قد لا يتم قبوله.
+إذا كنت تريد تقديم مساهمة كبيرة، افتح issue للسؤال قبل البدء بالعمل عليها. من المفيد متابعة المشروع لفترة (على GitHub، [يمكنك الضغط على "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) لتصلك إشعارات بكل النقاشات)، والتعرف على أعضاء المجتمع، قبل القيام بعمل قد لا يتم قبوله.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -491,7 +491,7 @@ related:
 
 إذا كان المشروع موجودًا على GitHub، فإليك كيفية تقديم (Pull Request):
 
-* **[قم بعمل Fork للمستودع](https://guides.github.com/activities/forking/)** ونسخه إلى جهازك محليًا (clone). اربط نسختك المحلية بالمستودع الأصلي "upstream" عن طريق إضافته كـ remote. قم بسحب التحديثات من "upstream" بشكل دوري لتبقى محدثًا، حتى تقل احتمالية حدوث تعارضات (merge conflicts) عند تقديم طلب السحب (pull request). (راجع التعليمات التفصيلية [هنا](https://help.github.com/articles/syncing-a-fork/).)
+* **[قم بعمل Fork للمستودع](https://guides.github.com/activities/forking/)** ونسخه إلى جهازك محليًا (clone). اربط نسختك المحلية بالمستودع الأصلي "upstream" عن طريق إضافته كـ remote. قم بسحب التحديثات من "upstream" بشكل دوري لتبقى محدثًا، حتى تقل احتمالية حدوث تعارضات (merge conflicts) عند تقديم طلب السحب (pull request). (راجع التعليمات التفصيلية [هنا](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[قم بإنشاء فرع (branch)](https://guides.github.com/introduction/flow/)** لإجراء تعديلاتك.
 * **قم بالإشارة إلى أي Issues** ذات صلة أو مستندات داعمة في طلب (PR) الخاص بك (على سبيل المثال: "Closes #37.").
 * **أضف لقطات شاشة قبل وبعد** إذا كانت تغييراتك تتضمن فروقات في HTML/CSS. اسحب الصور وأفلتها داخل محتوى طلب (pull request) الخاص بك.
diff --git a/_articles/ar/leadership-and-governance.md b/_articles/ar/leadership-and-governance.md
index 1d7146d739e..a882e2f4733 100644
--- a/_articles/ar/leadership-and-governance.md
+++ b/_articles/ar/leadership-and-governance.md
@@ -77,7 +77,7 @@ related:
 
 أدوات مثل [Vossibility](https://github.com/icecrime/vossibility-stack) يمكن أن تساعدك في تتبع من يساهم أو لا يساهم في المشروع بشكل عام. توثيق هذه المعلومات يمنع انطباع المجتمع بأن المشرفين هم مجموعة مغلقة تتخذ قراراتها بشكل خاص.
 
-أخيرًا، إذا كان مشروعك موجودًا على GitHub، فكر في نقل المشروع من حسابك الشخصي إلى منظمة (Organization) وإضافة على الأقل مشرف احتياطي واحد. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/)  تجعل إدارة الصلاحيات والمستودعات المتعددة أسهل، وتحمي إرث مشروعك من خلال [الملكية المشتركة](../building-community/#شارك-ملكية-مشروعك).
+أخيرًا، إذا كان مشروعك موجودًا على GitHub، فكر في نقل المشروع من حسابك الشخصي إلى منظمة (Organization) وإضافة على الأقل مشرف احتياطي واحد. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)  تجعل إدارة الصلاحيات والمستودعات المتعددة أسهل، وتحمي إرث مشروعك من خلال [الملكية المشتركة](../building-community/#شارك-ملكية-مشروعك).
 
 ## متى يجب أن أمنح شخصًا صلاحية التعديل؟
 
@@ -85,7 +85,7 @@ related:
 
 من ناحية أخرى، وخاصة في المشاريع الكبيرة والمعقدة، قد ترغب في منح صلاحية التعديل فقط للأشخاص الذين أثبتوا التزامهم بالمشروع، لا توجد طريقة صحيحة واحدة لذلك – افعل ما يجعلك أكثر راحة وثقة
 
-إذا كان مشروعك موجودًا على GitHub، يمكنك استخدام [الفروع المحمية](https://help.github.com/articles/about-protected-branches/) لإدارة من يمكنه رفع التعديلات إلى فرع معين، وتحديد الظروف التي يُسمح فيها بذلك.
+إذا كان مشروعك موجودًا على GitHub، يمكنك استخدام [الفروع المحمية](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) لإدارة من يمكنه رفع التعديلات إلى فرع معين، وتحديد الظروف التي يُسمح فيها بذلك.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ar/legal.md b/_articles/ar/legal.md
index 5e1cf548934..05618da069a 100644
--- a/_articles/ar/legal.md
+++ b/_articles/ar/legal.md
@@ -30,7 +30,7 @@ related:
 
 ## هل مشاريع GitHub العامة مفتوحة المصدر؟
 
-عند [إنشاء مشروع جديد](https://help.github.com/articles/creating-a-new-repository/) على GitHub، لديك الخيار لجعل المستودع **خاص** أو **عام**.
+عند [إنشاء مشروع جديد](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) على GitHub، لديك الخيار لجعل المستودع **خاص** أو **عام**.
 
 ![إنشاء مستودع](/assets/images/legal/repo-create-name.png)
 
@@ -44,7 +44,7 @@ related:
 
 [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://innovationgraph.github.com/global-metrics/licenses)، لكن هناك خيارات أخرى يمكن الاختيار منها. يمكنك العثور على النص الكامل لهذه الرخص، والتعليمات حول كيفية استخدامها، على [choosealicense.com](https://choosealicense.com/).
 
-عند إنشاء مشروع جديد على GitHub، سيُطلب منك [إضافة ترخيص](https://help.github.com/articles/open-source-licensing/).
+عند إنشاء مشروع جديد على GitHub، سيُطلب منك [إضافة ترخيص](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
  <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -95,7 +95,7 @@ related:
 
 ## هل يحتاج مشروعي إلى اتفاقية مساهم إضافية؟ {#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية}
 
-على الأرجح لا. بالنسبة لغالبية مشاريع المصدر المفتوح، فإن الترخيص مفتوح المصدر يُعد ضمنيًا بمثابة ترخيص **inbound** (من المساهمين) و **outbound** (إلى المساهمين والمستخدمين الآخرين). إذا كان مشروعك على GitHub، فإن شروط خدمة GitHub تجعل "inbound=outbound" [افتراضيًا وصريحًا](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+على الأرجح لا. بالنسبة لغالبية مشاريع المصدر المفتوح، فإن الترخيص مفتوح المصدر يُعد ضمنيًا بمثابة ترخيص **inbound** (من المساهمين) و **outbound** (إلى المساهمين والمستخدمين الآخرين). إذا كان مشروعك على GitHub، فإن شروط خدمة GitHub تجعل "inbound=outbound" [افتراضيًا وصريحًا](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 عملاً إداريًا على القائمين على صيانة المشروع، يمكن أن تخلق اتفاقية المساهم الإضافية (CLA) مقدار العمل الإضافي الذي تضيفه الاتفاقية حسب المشروع وطريقة التنفيذ. قد تتطلب الاتفاقية البسيطة من المساهمين فقط تأكيدًا، بنقرة واحدة، على أن لديهم الحقوق اللازمة للمساهمة بموجب ترخيص المصادر المفتوحة للمشروع، أما الاتفاقية الأكثر تعقيدًا فقد تتطلب مراجعة قانونية وموافقة رسمية من أصحاب عمل المساهمين.
 
diff --git a/_articles/ar/metrics.md b/_articles/ar/metrics.md
index 62d69629818..fb5c6219f50 100644
--- a/_articles/ar/metrics.md
+++ b/_articles/ar/metrics.md
@@ -39,7 +39,7 @@ related:
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-إذا كان مشروعك مستضافًا على GitHub, [يمكنك مشاهدة](https://help.github.com/articles/about-repository-graphs/#traffic) عدد الأشخاص الذين يزورون مشروعك ومن أين يأتون. من صفحة مشروعك، انقر على "Insights"، ثم "Traffic". في هذه الصفحة، يمكنك رؤية:
+إذا كان مشروعك مستضافًا على GitHub, [يمكنك مشاهدة](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) عدد الأشخاص الذين يزورون مشروعك ومن أين يأتون. من صفحة مشروعك، انقر على "Insights"، ثم "Traffic". في هذه الصفحة، يمكنك رؤية:
 
 * **إجمالي عدد مشاهدات الصفحة:** يخبرك بعدد مرات مشاهدة مشروعك
 
@@ -49,7 +49,7 @@ related:
 
 * **المحتوى الشائع:** يخبرك أين يذهب الزوار في مشروعك، موزعًا حسب عدد مرات مشاهدة الصفحة والزوار الفريدين.
 
-[نجوم GitHub](https://help.github.com/articles/about-stars/) يمكن أن تساعد أيضًا في توفير مقياس أساسي للشهرة. على الرغم من أن نجوم GitHub لا ترتبط بالضرورة بالتنزيلات والاستخدام، إلا أنها يمكن أن تخبرك بعدد الأشخاص الذين ينتبهون إلى عملك.
+[نجوم GitHub](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) يمكن أن تساعد أيضًا في توفير مقياس أساسي للشهرة. على الرغم من أن نجوم GitHub لا ترتبط بالضرورة بالتنزيلات والاستخدام، إلا أنها يمكن أن تخبرك بعدد الأشخاص الذين ينتبهون إلى عملك.
 
 قد ترغب أيضًا في [تتبع إمكانية الاكتشاف في أماكن محددة](https://opensource.com/business/16/6/pirate-metrics): على سبيل المثال، Google PageRank، أو حركة المرور المرجعية من موقع الويب الخاص بمشروعك، أو الإحالات من مشاريع أو مواقع ويب أخرى مفتوحة المصدر.
 
diff --git a/_articles/ar/starting-a-project.md b/_articles/ar/starting-a-project.md
index 62e1227819a..30816d0de10 100644
--- a/_articles/ar/starting-a-project.md
+++ b/_articles/ar/starting-a-project.md
@@ -108,9 +108,9 @@ related:
 
 بغض النظر عن المرحلة التي تقرر فيها فتح مصدر مشروعك، يجب أن يتضمن كل مشروع التوثيق التالي:
 
-* [ترخيص المصدر المفتوح](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)
-* [إرشادات المساهمة](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [ترخيص المصدر المفتوح](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [إرشادات المساهمة](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [قواعد السلوك](../code-of-conduct/)
 
 كمسؤول، ستساعدك هذه المكونات في توصيل التوقعات، وإدارة المساهمات، وحماية الحقوق القانونية للجميع (بما في ذلك حقوقك). تزيد بشكل كبير من فرص حصولك على تجربة إيجابية.
@@ -184,7 +184,7 @@ related:
 
 للمزيد من المساعدة في كتابة ملف CONTRIBUTING الخاص بك، راجع قالب دليل المساهمة لـ @nayafia [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) أو ["كيفية بناء CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) لـ @mozilla.
 
-اربط ملف CONTRIBUTING الخاص بك من README، حتى يراه المزيد من الناس. إذا [وضعت ملف CONTRIBUTING في مستودع مشروعك](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)، فسيربط GitHub تلقائيًا إلى ملفك عندما ينشئ مساهم issue أو يفتح pull request.
+اربط ملف CONTRIBUTING الخاص بك من README، حتى يراه المزيد من الناس. إذا [وضعت ملف CONTRIBUTING في مستودع مشروعك](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)، فسيربط GitHub تلقائيًا إلى ملفك عندما ينشئ مساهم issue أو يفتح pull request.
 
 ![إرشادات المساهمة](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -257,7 +257,7 @@ related:
 
 ## قائمة التحقق قبل الإطلاق
 
-هل أنت مستعد لفتح مصدر مشروعك؟ إليك قائمة تحقق للمساعدة. ضع علامة على جميع المربعات؟ أنت مستعد للانطلاق! [انقر على "نشر"](https://help.github.com/articles/making-a-private-repository-public/) وربت على ظهرك.
+هل أنت مستعد لفتح مصدر مشروعك؟ إليك قائمة تحقق للمساعدة. ضع علامة على جميع المربعات؟ أنت مستعد للانطلاق! [انقر على "نشر"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) وربت على ظهرك.
 
 **التوثيق**
 
diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 43b056c6271..360d8235fc4 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -165,7 +165,7 @@ You don't have to do everything yourself. Your project's community exists for a
 
 If you're looking for others to pitch in, start by asking around.
 
-One way to gain new contributors is to explicitly [label issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing their visibility.
+One way to gain new contributors is to explicitly [label issues that are simple enough for beginners to tackle](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing their visibility.
 
 When you see new contributors making repeated contributions, recognize their work by offering more responsibility. Document how others can grow into leadership roles if they wish.
 
@@ -215,7 +215,7 @@ One of the most important ways you can automate your project is by adding tests.
 
 Tests help contributors feel confident that they won't break anything. They also make it easier for you to review and accept contributions quickly. The more responsive you are, the more engaged your community can be.
 
-Set up automatic tests that will run on all incoming contributions, and ensure that your tests can easily be run locally by contributors. Require that all code contributions pass your tests before they can be submitted. You'll help set a minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) on GitHub can help ensure no change gets merged without your tests passing.
+Set up automatic tests that will run on all incoming contributions, and ensure that your tests can easily be run locally by contributors. Require that all code contributions pass your tests before they can be submitted. You'll help set a minimum standard of quality for all submissions. [Required status checks](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) on GitHub can help ensure no change gets merged without your tests passing.
 
 If you add tests, make sure to explain how they work in your CONTRIBUTING file.
 
diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index c94d9ef9a36..8ddd7f1cde4 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -214,7 +214,7 @@ related:
 Тестването помага на сътрудниците да се чувстват уверени, че няма да нарушат нищо. Те също така улесняват прегледа и бързото приемане на приноси. Колкото по-възприемчиви сте, толкова по-ангажирани ще бъдете. бъдете вашата общност.
 
 Настройте автоматични тестове за изпълнение на всички входящи приноси и се уверете, че могат да се изпълняват локално от сътрудниците. Изисква всички приноси на код да преминат през тестване, преди да могат да бъдат изпратени. Ще помогне за установяване на минимален стандарт за качество за всички приложения.
-[Необходими са проверки на състоянието](https://help.github.com/articles/about-required-status-checks/) в GitHub може да помогне да се гарантира, че никакви промени не се обединяват, без първо да преминете през тестване.
+[Необходими са проверки на състоянието](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) в GitHub може да помогне да се гарантира, че никакви промени не се обединяват, без първо да преминете през тестване.
 
 Ако добавите тестове, не забравяйте да обясните как работят във вашия CONTRIBUTING файл.
 
diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md
index 2d3ffd75b20..b1235b09e44 100644
--- a/_articles/bg/building-community.md
+++ b/_articles/bg/building-community.md
@@ -28,7 +28,7 @@ related:
 
 * **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#напишете-readme) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.
 * **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#напишете-вашите-указания-за-принос) и поддържате проблемите си актуални.
-* **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
+* **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.
 
 [Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията.
 
@@ -167,7 +167,7 @@ related:
 
 * **Дайте достъп за ангажиране на всеки сътрудник.** @felixge установи, че това кара хората [да бъдат по-развълнувани да усъвършенстват корекциите си](https://felixge.de/2013/03/11/the-pull-request-hack.html) и дори намери нови поддържащи за проекти, по които не е работил от известно време.
 
-* Ако проектът ви е в GitHub, **преместете проекта си от личния си акаунт в [Организация](https://help.github.com/articles/creating-a-new-organization-account/)** и добавете поне един резервен администратор. Организациите улесняват работата по проекти с външни сътрудници.
+* Ако проектът ви е в GitHub, **преместете проекта си от личния си акаунт в [Организация](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** и добавете поне един резервен администратор. Организациите улесняват работата по проекти с външни сътрудници.
 
 Реалността е, че [повечето проекти имат само](https://peerj.com/preprints/1233/) един или двама поддържащи, които вършат по-голямата част от работата. Колкото по-голям е вашият проект и колкото по-голяма е вашата общност, толкова по-лесно е да намерите помощ.
 
diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md
index 391fb43c374..a7da638aa0f 100644
--- a/_articles/bg/how-to-contribute.md
+++ b/_articles/bg/how-to-contribute.md
@@ -447,7 +447,7 @@ related:
 
 Преди да отворите проблем или заявка за изтегляне, проверете допринасящите документи на проекта (обикновено файл, наречен CONTRIBUTING или в README), за да видите дали трябва да включите нещо конкретно. Например, те могат да поискат да следвате шаблон или да изискват да използвате тестове.
 
-Ако искате да направите значителен принос, отворете проблем, който да попитате, преди да работите по него. Полезно е да гледате проекта известно време (в GitHub, [можете да щракнете върху "Гледане"](https://help.github.com/articles/watching-repositories/), за да бъдете уведомени за всички разговори) и да стигнете до познавайте членовете на общността, преди да вършите работа, която може да не бъде приета.
+Ако искате да направите значителен принос, отворете проблем, който да попитате, преди да работите по него. Полезно е да гледате проекта известно време (в GitHub, [можете да щракнете върху "Гледане"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications), за да бъдете уведомени за всички разговори) и да стигнете до познавайте членовете на общността, преди да вършите работа, която може да не бъде приета.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -482,7 +482,7 @@ related:
 
 Ако проектът е в GitHub, ето как да изпратите заявка за изтегляне:
 
-* **[Разклонете хранилището](https://guides.github.com/activities/forking/)** и го клонирайте локално. Свържете вашето локално към оригиналното хранилище "нагоре по веригата", като го добавите като дистанционно. Изтегляйте често промените от "нагоре по веригата", така че да сте в течение, така че когато изпратите заявката си за изтегляне, конфликтите при сливане ще бъдат по-малко вероятни. (Вижте по-подробни инструкции [тук](https://help.github.com/articles/syncing-a-fork/).)
+* **[Разклонете хранилището](https://guides.github.com/activities/forking/)** и го клонирайте локално. Свържете вашето локално към оригиналното хранилище "нагоре по веригата", като го добавите като дистанционно. Изтегляйте често промените от "нагоре по веригата", така че да сте в течение, така че когато изпратите заявката си за изтегляне, конфликтите при сливане ще бъдат по-малко вероятни. (Вижте по-подробни инструкции [тук](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Създайте клон](https://guides.github.com/introduction/flow/)** за вашите редакции.
 * **Посочете всички съответни проблеми** или подкрепяща документация във вашия PR (например "Затваря #37.")
 * **Включете екранни снимки преди и след**, ако вашите промени включват разлики в HTML/CSS. Плъзнете и пуснете изображенията в тялото на вашата заявка за изтегляне.
diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md
index 6748123f828..9e9636f9425 100644
--- a/_articles/bg/leadership-and-governance.md
+++ b/_articles/bg/leadership-and-governance.md
@@ -73,7 +73,7 @@ related:
 
 Инструменти като [Vossibility](https://github.com/icecrime/vossibility-stack) могат да ви помогнат публично да проследите кой (или не) прави принос към проекта. Документирането на тази информация избягва възприемането на общността, че поддържащите са клика, която взема решенията си частно.
 
-И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#споделете-собствеността-върху-вашия-проект).
+И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#споделете-собствеността-върху-вашия-проект).
 
 ## Кога трябва да дам на някого достъп за ангажиране?
 
@@ -81,7 +81,7 @@ related:
 
 От друга страна, особено за по-големи, по-сложни проекти, може да искате да дадете достъп за ангажиране само на хора, които са демонстрирали своя ангажимент. Няма един правилен начин да го направите - направете това, което ви прави най-удобно!
 
-Ако вашият проект е в GitHub, можете да използвате [защитени клонове](https://help.github.com/articles/about-protected-branches/), за да управлявате кой може да насочва към определен клон и при какви обстоятелства.
+Ако вашият проект е в GitHub, можете да използвате [защитени клонове](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches), за да управлявате кой може да насочва към определен клон и при какви обстоятелства.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md
index 054a20e862d..ace6e2128c5 100644
--- a/_articles/bg/legal.md
+++ b/_articles/bg/legal.md
@@ -28,7 +28,7 @@ related:
 
 ## Публичните GitHub проекти с отворен код ли са?
 
-Когато [създадете нов проект](https://help.github.com/articles/creating-a-new-repository/) в GitHub, имате опцията да направите хранилището **частно** или **публично**.
+Когато [създадете нов проект](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) в GitHub, имате опцията да направите хранилището **частно** или **публично**.
 
 ![Създаване на хранилище](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ related:
 
 [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://innovationgraph.github.com/global-metrics/licenses), но има и други опции за избор. Можете да намерите пълния текст на тези лицензи и инструкции как да ги използвате на [choosealicense.com](https://choosealicense.com/).
 
-Когато създадете нов проект в GitHub, ще бъдете [помолени да добавите лиценз](https://help.github.com/articles/open-source-licensing/).
+Когато създадете нов проект в GitHub, ще бъдете [помолени да добавите лиценз](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -90,7 +90,7 @@ related:
 
 ## Моят проект има ли нужда от споразумение за допълнителен сътрудник?
 
-Вероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят "inbound=outbound" [изрично по подразбиране](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Вероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят "inbound=outbound" [изрично по подразбиране](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Допълнително споразумение за сътрудник – често наричано Споразумение за лиценз на сътрудник (CLA) – може да създаде административна работа за поддържащите проекта. Колко работа добавя едно споразумение зависи от проекта и изпълнението. Обикновено споразумение може да изисква сътрудниците да потвърдят с едно щракване, че имат правата, необходими за принос съгласно лиценза за отворен код на проекта. По-сложно споразумение може да изисква правен преглед и подписване от работодателите на сътрудниците.
 
diff --git a/_articles/bg/metrics.md b/_articles/bg/metrics.md
index 47b617ee8dc..5adc1756755 100644
--- a/_articles/bg/metrics.md
+++ b/_articles/bg/metrics.md
@@ -37,7 +37,7 @@ related:
 
 ![Графика на трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Ако вашият проект се хоства в GitHub, [можете да видите](https://help.github.com/articles/about-repository-graphs/#traffic) колко хора попадат на вашия проект и откъде идват. От страницата на вашия проект щракнете върху "Прозрения", след това върху "Трафик". На тази страница можете да видите:
+Ако вашият проект се хоства в GitHub, [можете да видите](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) колко хора попадат на вашия проект и откъде идват. От страницата на вашия проект щракнете върху "Прозрения", след това върху "Трафик". На тази страница можете да видите:
 
 * **Общ брой показвания на страници:** Ви казва колко пъти е бил прегледан вашият проект
 
@@ -47,7 +47,7 @@ related:
 
 * **Популярно съдържание:** Ви казва къде отиват посетителите във вашия проект, разбити по показвания на страници и уникални посетители.
 
-[Звездите на GitHub](https://help.github.com/articles/about-stars/) също могат да помогнат за предоставяне на основна мярка за популярност. Въпреки че звездите на GitHub не са непременно свързани с изтегляния и използване, те могат да ви кажат колко хора обръщат внимание на работата ви.
+[Звездите на GitHub](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) също могат да помогнат за предоставяне на основна мярка за популярност. Въпреки че звездите на GitHub не са непременно свързани с изтегляния и използване, те могат да ви кажат колко хора обръщат внимание на работата ви.
 
 Може също да искате да [проследите откриваемостта на конкретни места](https://opensource.com/business/16/6/pirate-metrics): например Google PageRank, трафик от препоръчани потребители от уебсайта на вашия проект или препоръчани потребители от други отворени изходни проекти или уебсайтове.
 
diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md
index 9df5770a93d..72bbe31679a 100644
--- a/_articles/bg/starting-a-project.md
+++ b/_articles/bg/starting-a-project.md
@@ -106,9 +106,9 @@ _Свободен софтуер_ се отнася до същия набор 
 
 Без значение на кой етап решите да отворите проекта си, всеки проект трябва да включва следната документация:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 Като поддържащ, тези компоненти ще ви помогнат да съобщите очакванията, да управлявате приносите и да защитите законните права на всички (включително вашите собствени). Те значително увеличават шансовете ви за положително преживяване.
@@ -182,7 +182,7 @@ CONTRIBUTING файл казва на вашата публика как да у
 
 За повече помощ при писането на вашия CONTRIBUTING файл вижте @nayafia [шаблон за ръководство за допринасяне](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) или @mozilla ["Как да Създайте CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Връзка към вашия ПРИНОСЕН файл от вашия README, така че повече хора да го видят. Ако [поставите файла CONTRIBUTING в хранилището на вашия проект](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub автоматично ще се свърже с вашия файл, когато участник създаде проблем или отваря заявка за изтегляне.
+Връзка към вашия ПРИНОСЕН файл от вашия README, така че повече хора да го видят. Ако [поставите файла CONTRIBUTING в хранилището на вашия проект](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub автоматично ще се свърже с вашия файл, когато участник създаде проблем или отваря заявка за изтегляне.
 
 ![Указания за принос](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ CONTRIBUTING файл казва на вашата публика как да у
 
 ## Вашият контролен списък преди стартиране
 
-Готови ли сте да отворите вашия проект? Ето контролен списък за помощ. Поставете отметка във всички квадратчета? Готови сте за работа! [Щракнете върху "публикувай"](https://help.github.com/articles/making-a-private-repository-public/) и се потупайте по рамото.
+Готови ли сте да отворите вашия проект? Ето контролен списък за помощ. Поставете отметка във всички квадратчета? Готови сте за работа! [Щракнете върху "публикувай"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) и се потупайте по рамото.
 
 **Документация**
 
diff --git a/_articles/bn/best-practices.md b/_articles/bn/best-practices.md
index dea8852c5b4..9d0ecccf082 100644
--- a/_articles/bn/best-practices.md
+++ b/_articles/bn/best-practices.md
@@ -167,7 +167,7 @@ related:
 
 যদি আপনি অন্যদের সাহায্য করার জন্য খুঁজছেন, তাহলে আশেপাশে জিজ্ঞাসা করে শুরু করুন।
 
-নতুন অবদানকারীদের আকর্ষণ করার একটি উপায় হল [এমন সমস্যাগুলিকে স্পষ্টভাবে লেবেল করা যা নতুনদের জন্য যথেষ্ট সহজ](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) । এরপর GitHub প্ল্যাটফর্মের বিভিন্ন স্থানে এই সমস্যাগুলি তুলে ধরবে, যার ফলে তাদের দৃশ্যমানতা বৃদ্ধি পাবে।
+নতুন অবদানকারীদের আকর্ষণ করার একটি উপায় হল [এমন সমস্যাগুলিকে স্পষ্টভাবে লেবেল করা যা নতুনদের জন্য যথেষ্ট সহজ](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels) । এরপর GitHub প্ল্যাটফর্মের বিভিন্ন স্থানে এই সমস্যাগুলি তুলে ধরবে, যার ফলে তাদের দৃশ্যমানতা বৃদ্ধি পাবে।
 
 যখন আপনি নতুন অবদানকারীদের বারবার অবদান রাখতে দেখেন, তখন আরও দায়িত্ব প্রদানের মাধ্যমে তাদের কাজকে স্বীকৃতি দিন। অন্যরা কীভাবে ইচ্ছা করলে নেতৃত্বের ভূমিকায় পরিণত হতে পারে তা নথিভুক্ত করুন।
 
@@ -217,7 +217,7 @@ related:
 
 পরীক্ষাগুলি অবদানকারীদের আত্মবিশ্বাসী বোধ করতে সাহায্য করে যে তারা কোনও কিছু ভাঙবে না। এগুলি আপনার জন্য অবদানগুলি পর্যালোচনা করা এবং দ্রুত গ্রহণ করা সহজ করে তোলে। আপনি যত বেশি প্রতিক্রিয়াশীল হবেন, আপনার সম্প্রদায় তত বেশি জড়িত হতে পারবে।
 
-সমস্ত আগত অবদানের উপর স্বয়ংক্রিয় পরীক্ষা সেট আপ করুন এবং নিশ্চিত করুন যে আপনার পরীক্ষাগুলি স্থানীয়ভাবে অবদানকারীদের দ্বারা সহজেই চালানো যেতে পারে। জমা দেওয়ার আগে সমস্ত কোড অবদানগুলিকে আপনার পরীক্ষায় উত্তীর্ণ হতে হবে। আপনি সমস্ত জমা দেওয়ার জন্য মানের একটি ন্যূনতম মান নির্ধারণ করতে সহায়তা করবেন। GitHub-এ [প্রয়োজনীয় স্থিতি পরীক্ষা](https://help.github.com/articles/about-required-status-checks/) নিশ্চিত করতে সাহায্য করতে পারে যে আপনার পরীক্ষাগুলি পাস না করে কোনও পরিবর্তন একত্রিত না হয়।
+সমস্ত আগত অবদানের উপর স্বয়ংক্রিয় পরীক্ষা সেট আপ করুন এবং নিশ্চিত করুন যে আপনার পরীক্ষাগুলি স্থানীয়ভাবে অবদানকারীদের দ্বারা সহজেই চালানো যেতে পারে। জমা দেওয়ার আগে সমস্ত কোড অবদানগুলিকে আপনার পরীক্ষায় উত্তীর্ণ হতে হবে। আপনি সমস্ত জমা দেওয়ার জন্য মানের একটি ন্যূনতম মান নির্ধারণ করতে সহায়তা করবেন। GitHub-এ [প্রয়োজনীয় স্থিতি পরীক্ষা](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) নিশ্চিত করতে সাহায্য করতে পারে যে আপনার পরীক্ষাগুলি পাস না করে কোনও পরিবর্তন একত্রিত না হয়।
 
 যদি আপনি পরীক্ষা যোগ করেন, তাহলে আপনার CONTRIBUTING ফাইলে সেগুলি কীভাবে কাজ করে তা ব্যাখ্যা করতে ভুলবেন না।
 
diff --git a/_articles/bn/building-community.md b/_articles/bn/building-community.md
index 7d3a9a46aae..ab7bf815766 100644
--- a/_articles/bn/building-community.md
+++ b/_articles/bn/building-community.md
@@ -28,7 +28,7 @@ Start with your documentation:
 
 * **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started.
 * **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date.
-* **Good first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level.
+* **Good first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level.
 
 [GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) showed incomplete or confusing documentation is the biggest problem for open source users. Good documentation invites people to interact with your project. Eventually, someone will open an issue or pull request. Use these interactions as opportunities to move them down the funnel.
 
@@ -167,7 +167,7 @@ See if you can find ways to share ownership with your community as much as possi
 
 * **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile.
 
-* If your project is on GitHub, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators.
+* If your project is on GitHub, **move your project from your personal account to an [Organization](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators.
 
 The reality is that [most projects only have](https://peerj.com/preprints/1233/) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help.
 
diff --git a/_articles/bn/how-to-contribute.md b/_articles/bn/how-to-contribute.md
index f353675453f..45dca06d2de 100644
--- a/_articles/bn/how-to-contribute.md
+++ b/_articles/bn/how-to-contribute.md
@@ -447,7 +447,7 @@ If you can't find your idea elsewhere, you're ready to make a move. If the proje
 
 Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests.
 
-If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted.
+If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) to be notified of all conversations), and get to know community members, before doing work that might not get accepted.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -482,7 +482,7 @@ A pull request doesn't have to represent finished work. It's usually better to o
 
 If the project is on GitHub, here's how to submit a pull request:
 
-* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
 * **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
 * **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
diff --git a/_articles/bn/leadership-and-governance.md b/_articles/bn/leadership-and-governance.md
index 45a5b200601..4288eb0c898 100644
--- a/_articles/bn/leadership-and-governance.md
+++ b/_articles/bn/leadership-and-governance.md
@@ -73,7 +73,7 @@ Once you've established leadership roles, don't forget to document how people ca
 
 Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately.
 
-Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project).
+Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project).
 
 ## When should I give someone commit access?
 
@@ -81,7 +81,7 @@ Some people think you should give commit access to everybody who makes a contrib
 
 On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable!
 
-If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances.
+If your project is on GitHub, you can use [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) to manage who can push to a particular branch, and under which circumstances.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/bn/legal.md b/_articles/bn/legal.md
index 168e5b5dae5..5f4ac3cda22 100644
--- a/_articles/bn/legal.md
+++ b/_articles/bn/legal.md
@@ -28,7 +28,7 @@ Finally, your project may have dependencies with license requirements that you w
 
 ## Are public GitHub projects open source?
 
-When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**.
+When you [create a new project](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) on GitHub, you have the option to make the repository **private** or **public**.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ You're in luck, because today, open source licenses are standardized and easy to
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
 
-When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+When you create a new project on GitHub, you'll be [asked to add a license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -90,7 +90,7 @@ Alternatively, you can have contributors pre-approve certain license changes via
 
 ## Does my project need an additional contributor agreement?
 
-Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers.
 
diff --git a/_articles/bn/metrics.md b/_articles/bn/metrics.md
index 76af752c9e7..18093a6dae5 100644
--- a/_articles/bn/metrics.md
+++ b/_articles/bn/metrics.md
@@ -37,7 +37,7 @@ Before anybody can use or contribute back to your project, they need to know it
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see:
+If your project is hosted on GitHub, [you can view](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see:
 
 * **Total page views:** Tells you how many times your project was viewed
 
@@ -47,7 +47,7 @@ If your project is hosted on GitHub, [you can view](https://help.github.com/arti
 
 * **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
 
 You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites.
 
diff --git a/_articles/bn/starting-a-project.md b/_articles/bn/starting-a-project.md
index 9fc017c85c9..c73c381e4e5 100644
--- a/_articles/bn/starting-a-project.md
+++ b/_articles/bn/starting-a-project.md
@@ -106,9 +106,9 @@ Generally speaking, you should open source your project when you feel comfortabl
 
 No matter which stage you decide to open source your project, every project should include the following documentation:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience.
@@ -182,7 +182,7 @@ Over time, you might add other frequently asked questions to your CONTRIBUTING f
 
 For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
+Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ It isn't necessary to write a style guide for your project when you're just star
 
 ## Your pre-launch checklist
 
-Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back.
+Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) and pat yourself on the back.
 
 **Documentation**
 
diff --git a/_articles/building-community.md b/_articles/building-community.md
index d8985713137..bd6996ef6bc 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -28,7 +28,7 @@ Start with your documentation:
 
 * **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started.
 * **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date.
-* **Good first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level.
+* **Good first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level.
 
 [GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) showed incomplete or confusing documentation is the biggest problem for open source users. Good documentation invites people to interact with your project. Eventually, someone will open an issue or pull request. Use these interactions as opportunities to move them down the funnel.
 
@@ -167,7 +167,7 @@ See if you can find ways to share ownership with your community as much as possi
 
 * **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile.
 
-* If your project is on GitHub, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators.
+* If your project is on GitHub, **move your project from your personal account to an [Organization](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators.
 
 The reality is that [most projects only have](https://peerj.com/preprints/1233/) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help.
 
diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md
index e4402da32af..3f95f252ee6 100644
--- a/_articles/de/best-practices.md
+++ b/_articles/de/best-practices.md
@@ -179,7 +179,7 @@ Sie müssen nicht alles selbst machen. Die Gemeinschaft Ihres Projekts existiert
 
 Wenn Sie auf der Suche nach Mitwirkenden sind, fragen Sie doch einfach mal herum.
 
-Sie können auch [Issues, die für Anfänger einfach genug sind, explizit markieren (Englisch)](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden.
+Sie können auch [Issues, die für Anfänger einfach genug sind, explizit markieren (Englisch)](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden.
 
 Wenn Sie neue Mitwirkende bemerken, die wiederholt Beiträge leisten, erkennen Sie deren Arbeit an, indem Sie ihnen mehr Verantwortung anbieten. Dokumentieren Sie, wie andere in Führungsrollen hineinwachsen können, wenn sie es wünschen.
 
@@ -241,7 +241,7 @@ Eine der wichtigsten Möglichkeiten, wie Sie Ihr Projekt automatisieren können,
 
 Tests geben Mitwirkenden den Mut zu Änderungsvorschlägen, denn sie können nichts (unbemerkt) kaputt machen. Sie erleichtern es sich damit auch selbst, Beiträge schnell zu prüfen und anzunehmen. Je reaktionsschneller Sie sind, desto engagierter kann Ihre Gemeinschaft sein.
 
-Richten Sie automatische Tests ein, die bei allen eingehenden Beiträgen ausgeführt werden und stellen Sie sicher, dass Ihre Tests problemlos lokal von den Mitwirkenden ausgeführt werden können. Verlangen Sie, dass alle Codebeiträge Ihre Tests bestehen, bevor sie eingereicht werden können. Sie sichern einen Mindeststandards für die Qualität aller Einreichungen. [Verpflichtende Status-Checks](https://help.github.com/articles/about-required-status-checks/) auf GitHub können dazu beitragen, dass keine Änderungsvorschläge angenommen werden, die nicht Ihre Tests bestanden werden.
+Richten Sie automatische Tests ein, die bei allen eingehenden Beiträgen ausgeführt werden und stellen Sie sicher, dass Ihre Tests problemlos lokal von den Mitwirkenden ausgeführt werden können. Verlangen Sie, dass alle Codebeiträge Ihre Tests bestehen, bevor sie eingereicht werden können. Sie sichern einen Mindeststandards für die Qualität aller Einreichungen. [Verpflichtende Status-Checks](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) auf GitHub können dazu beitragen, dass keine Änderungsvorschläge angenommen werden, die nicht Ihre Tests bestanden werden.
 
 Wenn Sie Tests hinzufügen, erklären Sie deren Funktionsweise in Ihrer CONTRIBUTING-Datei.
 
diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
index 8415d5ff371..7d15242f65e 100644
--- a/_articles/de/building-community.md
+++ b/_articles/de/building-community.md
@@ -28,7 +28,7 @@ Beginnen Sie mit der Dokumentation:
 
 * **Helfen Sie beim Einstieg in ihr Projekt.** [Eine freundliche README](../starting-a-project/#eine-readme-schreiben) und anschauliche Codebeispiele erleichtern Allen, die auf Ihr Projekt stoßen, den Einstieg.
 * **Erklären Sie in klaren Worten, wie Leute beitragen sollen**, bspw. in [einer CONTRIBUTING-Datei](../starting-a-project/#ihre-beitragsrichtlinien-aufschreiben), und indem Sie die Issues stets aktuell halten.
-* **Good first issues**: Um neuen Mitwirkenden den Einstieg zu erleichtern, sollten Sie [für Anfänger\*innen geeignete Issues explizit kenntlich machen (Englisch)](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden, ohne sich erst durch vermutlich zu schwere Issues durchkämpfen zu müssen.
+* **Good first issues**: Um neuen Mitwirkenden den Einstieg zu erleichtern, sollten Sie [für Anfänger\*innen geeignete Issues explizit kenntlich machen (Englisch)](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden, ohne sich erst durch vermutlich zu schwere Issues durchkämpfen zu müssen.
 
 [GitHubs Open-Source-Umfrage aus dem Jahr 2017](http://opensourcesurvey.org/2017/) zeigte, dass unvollständige oder verwirrende Dokumentation das größte Problem für Open-Source-Anwender\*innen ist. Eine gute Dokumentation lädt zur Interaktion mit Ihrem Projekt ein. Wenn jemand ein Issue oder Pull Request erstellt, bietet sich für Sie die Möglichkeit, diese Person durch den Trichter zu bugsieren.
 
@@ -187,7 +187,7 @@ Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie mögli
 
 * **Geben Sie allen Mitwirkenden Schreibzugriff.** @felixge fand heraus, dass dies Leute [zu mehr Feinschliff ihrer Beiträge anspornt](https://felixge.de/2013/03/11/the-pull-request-hack.html), und gewann sogar neue Maintainer\*innen für Projekte, an denen er selbst schon eine Weile nicht mehr arbeitete.
 
-* Wenn Ihr Projekt auf GitHub liegt, **verschieben Sie es von Ihrem Privat-Konto in das einer [Organisation](https://help.github.com/articles/creating-a-new-organization-account/)** und fügen Sie zur Sicherheit mindestens eine\*n weitere\*n Administrator\*in hinzu. Organisationen machen die Zusammenarbeit mit externen Mithelfenden einfacher.
+* Wenn Ihr Projekt auf GitHub liegt, **verschieben Sie es von Ihrem Privat-Konto in das einer [Organisation](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** und fügen Sie zur Sicherheit mindestens eine\*n weitere\*n Administrator\*in hinzu. Organisationen machen die Zusammenarbeit mit externen Mithelfenden einfacher.
 
 Realistischerweise haben [die meisten Projekte](https://peerj.com/preprints/1233/) nur einen oder zwei Verantwortliche, welche die meiste Arbeit erledigen. Ja größer Ihr Projekt, und je größer seine Nutzer\*innengemeinschaft, desto einfacher wird es sein, Hilfe zu finden.
 
diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index d1036fb1900..42e7b3e8245 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -537,7 +537,7 @@ Wenn Sie Ihre Idee woanders nicht finden können, sind Sie bereit für den erste
 
 Bevor Sie ein Issue oder einen Pull Request öffnen, überprüfen Sie die Beitragsdokumentationen des Projekts (normalerweise eine Datei namens CONTRIBUTING, oder in der README), um zu verstehen, was in Anfragen erwünscht ist. Beispielsweise kann das Projekt verlangen, dass Sie einer Vorlage folgen oder Tests verwenden.
 
-Wenn Sie einen substantiellen Beitrag leisten wollen, öffnen Sie einen Issue, bevor Sie daran arbeiten. Bevor Sie Arbeiten ausführen, die möglicherweise nicht angenommen werden, schauen Sie sich das Projekt lieber eine Weile an (auf GitHub, [auf "Watch" klicken](https://help.github.com/articles/watching-repositories/), um über alle Konversationen informiert zu werden), und lernen die Community-Mitglieder kennen.
+Wenn Sie einen substantiellen Beitrag leisten wollen, öffnen Sie einen Issue, bevor Sie daran arbeiten. Bevor Sie Arbeiten ausführen, die möglicherweise nicht angenommen werden, schauen Sie sich das Projekt lieber eine Weile an (auf GitHub, [auf "Watch" klicken](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications), um über alle Konversationen informiert zu werden), und lernen die Community-Mitglieder kennen.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -576,7 +576,7 @@ Einen Pull Request muss keine fertige Arbeit darstellen. Es ist in der Regel bes
 
 Wenn das Projekt auf GitHub läuft, können Sie hier einen Pull Request stellen:
 
-* **[Forken Sie das Repository](https://guides.github.com/activities/forking/)** und klonen Sie es lokal. Verbinden Sie Ihr lokales mit dem ursprünglichen "upstream"-Repository, indem Sie es als Remote hinzufügen. Pullen Sie Änderungen von "upstream" möglichst oft, damit Sie auf dem Laufenden bleiben, und Konflikte beim Einreichen Ihres Pull Requests weniger wahrscheinlich werden. ([detailliertere Anweisungen finden Sie hier](https://help.github.com/articles/syncing-a-fork/).)
+* **[Forken Sie das Repository](https://guides.github.com/activities/forking/)** und klonen Sie es lokal. Verbinden Sie Ihr lokales mit dem ursprünglichen "upstream"-Repository, indem Sie es als Remote hinzufügen. Pullen Sie Änderungen von "upstream" möglichst oft, damit Sie auf dem Laufenden bleiben, und Konflikte beim Einreichen Ihres Pull Requests weniger wahrscheinlich werden. ([detailliertere Anweisungen finden Sie hier](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Erstellen Sie einen Branch](https://guides.github.com/introduction/flow/)** für Ihre Änderungen.
 * **Verweisen Sie auf relevante Issues** oder unterstützende Dokumentation in Ihrem PR (z.B. "Closes #37").
 * **Fügen Sie Vorher-/Nachher-Bildschirmfotos hinzu**, wenn Ihre Änderungen Unterschiede in HTML/CSS enthalten. Ziehen Sie die Bilder per Drag & Drop in den Textkörper Ihres Pull Requests.
diff --git a/_articles/de/leadership-and-governance.md b/_articles/de/leadership-and-governance.md
index 20aeffd0014..c6704afaf87 100644
--- a/_articles/de/leadership-and-governance.md
+++ b/_articles/de/leadership-and-governance.md
@@ -85,7 +85,7 @@ Vergessen Sie nicht, nach der Festlegung von Führungsrollen zu dokumentieren, w
 
 Tools wie [Vossibility](https://github.com/icecrime/vossibility-stack) können Ihnen dabei helfen, öffentlich zu verfolgen, wer zum Projekt beiträgt (oder nicht). Die Dokumentation dieser Informationen beugt dem Eindruck vor, dass eine Maintainer\*innen-Clique ihre Privatinteressen durchsetzen würde.
 
-Wenn sich Ihr Projekt auf GitHub befindet, können Sie Ihr Projekt von Ihrem persönlichen Konto in eine Organisation verschieben und mindestens einen Backup-Administrator einrichten. [GitHub-Organisationen](https://help.github.com/articles/creating-a-new-organization-account/) erleichtern die Verwaltung von mehreren Repositories und Berechtigungen, und schützen ihr Projektarchiv durch [gemeinsame Verantwortung](../building-community/#teilen-sie-die-eigentümerschaft-an-ihrem-projekt).
+Wenn sich Ihr Projekt auf GitHub befindet, können Sie Ihr Projekt von Ihrem persönlichen Konto in eine Organisation verschieben und mindestens einen Backup-Administrator einrichten. [GitHub-Organisationen](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) erleichtern die Verwaltung von mehreren Repositories und Berechtigungen, und schützen ihr Projektarchiv durch [gemeinsame Verantwortung](../building-community/#teilen-sie-die-eigentümerschaft-an-ihrem-projekt).
 
 ## Wann sollte ich jemandem Commit-Rechte geben?
 
@@ -93,7 +93,7 @@ Einige Leute denken, dass Sie allen Commit-Zugang geben sollten, die einen Beitr
 
 Andererseits (besonders bei größeren, komplexeren Projekten) möchten Sie vielleicht nur Personen zu Commits berechtigen, die ihr Engagement unter Beweis gestellt haben. Es gibt hier nicht _den einen_ richtigen Weg. Tun Sie, was Ihnen behagt!
 
-Wenn sich Ihr Projekt auf GitHub befindet, können Sie unter [protected branches](https://help.github.com/articles/about-protected-branches/) verwalten, wer unter welchen Umständen auf einen bestimmten Branch committen darf.
+Wenn sich Ihr Projekt auf GitHub befindet, können Sie unter [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) verwalten, wer unter welchen Umständen auf einen bestimmten Branch committen darf.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index 778710436ec..a2d905bc547 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -28,7 +28,7 @@ Schlussendlich könnte Ihr Projekt auch von anderen abhängen, die wiederum Lize
 
 ## Sind publizierte GitHub-Projekte Open-Source?
 
-Wenn Sie [ein neues Projekt auf GitHub erstellen](https://help.github.com/articles/creating-a-new-repository/), können Sie dies **öffentlich** oder **privat** tun.
+Wenn Sie [ein neues Projekt auf GitHub erstellen](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository), können Sie dies **öffentlich** oder **privat** tun.
 
 ![Ein Repo erstellen](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Sie haben Glück, denn Open-Source-Lizenzen sind heutzutage standardisiert und e
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), und [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sind die populärsten Open-Source-Lizenzen, aber es gibt auch andere zur Auswahl. Sie finden deren Volltexte, sowie Anleitungen zur deren Nutzung auf [choosealicense.com](https://choosealicense.com/), sowie eine Gruppierung nach Lizenztyp auf [ifrOSS.org/lizenz-center](http://www.ifross.org/lizenz-center).
 
-Wenn Sie ein neues Projekt auf GitHub anlegen, wird Ihnen [die Nutzung einer Lizenz vorgeschlagen](https://help.github.com/articles/open-source-licensing/).
+Wenn Sie ein neues Projekt auf GitHub anlegen, wird Ihnen [die Nutzung einer Lizenz vorgeschlagen](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -92,7 +92,7 @@ Alternativ können Sie auch im Voraus bestimmte Lizenzänderungen unter bestimmt
 
 ## Benötigt mein Projekt eine zusätzliche Kontributionsvereinbarung?
 
-Wahrscheinlich nicht. Für die überwiegende Mehrheit der Open-Source-Projekte gilt eine Open-Source-Lizenz implizit sowohl für reinkommende Beiträge als auch ausgehend an andere Mitwirkende und Benutzer\*innen. Wenn Ihr Projekt auf GitHub steht, machen GitHubs Terms of Service diese "inbound=outbound" genannte Praxis zum [expliziten Standard](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Wahrscheinlich nicht. Für die überwiegende Mehrheit der Open-Source-Projekte gilt eine Open-Source-Lizenz implizit sowohl für reinkommende Beiträge als auch ausgehend an andere Mitwirkende und Benutzer\*innen. Wenn Ihr Projekt auf GitHub steht, machen GitHubs Terms of Service diese "inbound=outbound" genannte Praxis zum [expliziten Standard](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Eine zusätzliche Kontributionsvereinbarung - oft auch Contributor License Agreement (CLA) genannt - kann Verwaltungsarbeit für die Projektbetreuer\*in schaffen. Hierbei hängt der Umfang der zusätzlichen Arbeit vom Projekt und der Implementierung ab. Eine einfache Vereinbarung erfordert, dass die Mitwirkenden mit einem Klick bestätigen, dass sie die erforderlichen Rechte innehaben, um zum Projekts im Rahmen dessen Open-Source-Lizenz beizutragen.
 
diff --git a/_articles/de/metrics.md b/_articles/de/metrics.md
index 2fbe5e037d7..01b55425528 100644
--- a/_articles/de/metrics.md
+++ b/_articles/de/metrics.md
@@ -39,7 +39,7 @@ Bevor Leute Ihr Projekt nutzen oder zu ihm beitragen können, müssen sie wissen
 
 ![Besucherzahlen](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Wenn Ihr Projekt auf GitHub gehostet wird, [können Sie sich ansehen](https://help.github.com/articles/about-repository-graphs/#traffic), wie viele Personen Ihr Projekt finden und wie sie es gefunden haben. Im Repo Ihres Projektes, klicken Sie "Insights" und dann "Traffic". Auf der Seite sehen Sie:
+Wenn Ihr Projekt auf GitHub gehostet wird, [können Sie sich ansehen](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository), wie viele Personen Ihr Projekt finden und wie sie es gefunden haben. Im Repo Ihres Projektes, klicken Sie "Insights" und dann "Traffic". Auf der Seite sehen Sie:
 
 * **Views** zeigen an, wie oft Ihr Projekt angesehen wurde.
 
@@ -49,7 +49,7 @@ Wenn Ihr Projekt auf GitHub gehostet wird, [können Sie sich ansehen](https://he
 
 * **Popular content** zeigt, wohin Besucher\*innen auf Ihrer Projektseite gehen, aufgeschlüsselt nach Seitenaufrufen und einzelnen Besucher\*innen.
 
-[GitHub-Sterne](https://help.github.com/articles/about-stars/) korrelieren nicht unbedingt mit Downloads und Nutzung, aber zeigen Ihnen, wie viele Menschen Ihre Arbeit schätzen.
+[GitHub-Sterne](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) korrelieren nicht unbedingt mit Downloads und Nutzung, aber zeigen Ihnen, wie viele Menschen Ihre Arbeit schätzen.
 
 Vielleicht möchten Sie auch [die Auffindbarkeit an bestimmten Orten verfolgen](https://opensource.com/business/16/6/pirate-metrics): z.B. Google PageRank, von Ihrer Projektwebsite ausgehende Empfehlungen, oder eingehende Empfehlungen anderer Open-Source-Projekte oder -Webseiten.
 
diff --git a/_articles/de/starting-a-project.md b/_articles/de/starting-a-project.md
index 83b4fcd4ca3..a18d7e9442d 100644
--- a/_articles/de/starting-a-project.md
+++ b/_articles/de/starting-a-project.md
@@ -118,9 +118,9 @@ Im Allgemeinen können Sie sich für Open-Source entscheiden, wenn Sie möchten,
 
 Unabhängig davon, in welcher Phase Sie sich für Open-Source entscheiden, sollte jedes Projekt die folgende Dokumentation enthalten:
 
-* [Eine Open-Source-Lizenz](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
-* [Eine README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
-* [Beitragsrichtlinien](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Eine Open-Source-Lizenz](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [Eine README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Beitragsrichtlinien](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [einen Verhaltenskodex](../code-of-conduct/)
 
 Als Maintainer\*in helfen Ihnen diese Komponenten, Erwartungen zu kommunizieren, Beiträge zu verwalten und die gesetzlichen Rechte aller (einschließlich Ihrer eigenen) zu schützen. Sie tragen zudem zu einer positiven Erfahrung in Ihrem Projekt bei.
@@ -201,7 +201,7 @@ Im Laufe der Zeit können Sie weitere häufig gestellte Fragen zu Ihrer CONTRIBU
 
 @nayafia's [CONTRIBUTING-Vorlage](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) oder @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) helfen Ihnen, Ihre Beitragsrichtlinien zu entwerfen.
 
-Verlinken Sie Ihre CONTRIBUTING-Datei in Ihrer README, damit sie gleich bemerkt wird. Wenn Sie sie zudem [in Ihr Repo einchecken](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), wird GitHub automatisch auf sie aufmerksam machen, wenn jemand ein Issue oder Pull Request erstellt.
+Verlinken Sie Ihre CONTRIBUTING-Datei in Ihrer README, damit sie gleich bemerkt wird. Wenn Sie sie zudem [in Ihr Repo einchecken](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), wird GitHub automatisch auf sie aufmerksam machen, wenn jemand ein Issue oder Pull Request erstellt.
 
 ![Beitragsrichtlinien](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -282,7 +282,7 @@ Eine Stilrichtlinie ist nicht sofort zum Start Ihres Projekts nötig, und vielle
 
 ## Ihre Checkliste zur Startvorbreitung
 
-Bereit für den Start Ihres Open-Source-Projektes? Diese Checkliste hilft Ihnen dabei. Alle Stationen bereit? Dann los! [Klicken Sie auf "publish"](https://help.github.com/articles/making-a-private-repository-public/) und klopfen Sie sich auf die Schulter.
+Bereit für den Start Ihres Open-Source-Projektes? Diese Checkliste hilft Ihnen dabei. Alle Stationen bereit? Dann los! [Klicken Sie auf "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) und klopfen Sie sich auf die Schulter.
 
 **Dokumentation**
 
diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index e4389724d1a..7bd19e2e0e1 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -165,7 +165,7 @@ related:
 
 Αν ψάχνετε για άλλους να συνεισφέρουν, ξεκινήστε ρωτώντας γύρω σας.
 
-Ένας τρόπος για να κερδίσετε νέους συνεισφέροντες είναι να επισημάνετε ρητά [θέματα που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα ζητήματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας την προβολή τους.
+Ένας τρόπος για να κερδίσετε νέους συνεισφέροντες είναι να επισημάνετε ρητά [θέματα που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα ζητήματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας την προβολή τους.
 
 Όταν βλέπετε νέους συνεισφέροντες να κάνουν επαναλαμβανόμενες συνεισφορές, αναγνωρίστε το έργο τους προσφέροντας περισσότερες ευθύνες. Τεκμηριώστε τον τρόπο με τον οποίο οι άλλοι μπορούν να εξελιχθούν σε ηγετικούς ρόλους αν το επιθυμούν.
 
@@ -215,7 +215,7 @@ related:
 
 Οι δοκιμές βοηθούν τους συνεισφέροντες να αισθάνονται σίγουροι ότι δεν θα χαλάσουν τίποτα. Επίσης, σας διευκολύνουν να αναθεωρείτε και να αποδέχεστε γρήγορα τις συνεισφορές. Όσο πιο ευέλικτοι είστε, τόσο πιο αφοσιωμένη μπορεί να είναι η κοινότητά σας.
 
-Ορίστε αυτόματες δοκιμές που θα εκτελούνται σε όλες τις εισερχόμενες συνεισφορές και βεβαιωθείτε ότι οι δοκιμές σας μπορούν εύκολα να εκτελούνται τοπικά από τους συνεισφέροντες. Απαιτήστε ότι όλες οι συνεισφορές κώδικα περνούν τις δοκιμές σας πριν υποβληθούν. Θα βοηθήσετε στον καθορισμό ενός ελάχιστου προτύπου ποιότητας για όλες τις υποβολές. Οι [Απαιτούμενοι έλεγχοι κατάστασης](https://help.github.com/articles/about-required-status-checks/) στο GitHub μπορούν να βοηθήσουν να διασφαλιστεί ότι καμία αλλαγή δεν συγχωνεύεται χωρίς να έχουν περάσει οι δοκιμές σας.
+Ορίστε αυτόματες δοκιμές που θα εκτελούνται σε όλες τις εισερχόμενες συνεισφορές και βεβαιωθείτε ότι οι δοκιμές σας μπορούν εύκολα να εκτελούνται τοπικά από τους συνεισφέροντες. Απαιτήστε ότι όλες οι συνεισφορές κώδικα περνούν τις δοκιμές σας πριν υποβληθούν. Θα βοηθήσετε στον καθορισμό ενός ελάχιστου προτύπου ποιότητας για όλες τις υποβολές. Οι [Απαιτούμενοι έλεγχοι κατάστασης](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) στο GitHub μπορούν να βοηθήσουν να διασφαλιστεί ότι καμία αλλαγή δεν συγχωνεύεται χωρίς να έχουν περάσει οι δοκιμές σας.
 
 Αν προσθέσετε δοκιμές, φροντίστε να εξηγήσετε πώς λειτουργούν στο αρχείο CONTRIBUTING.
 
diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 12d11d82e45..918609586a4 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -28,7 +28,7 @@ related:
 
 * **Κάντε εύκολο για κάποιον να χρησιμοποιήσει το πρότζεκτ σας.** [Ένα φιλικό README](../starting-a-project/#γράφοντας-ένα-readme) και σαφή παραδείγματα κώδικα θα διευκολύνουν οποιονδήποτε βρεθεί στο πρότζεκτ σας να ξεκινήσει.
 * **Εξηγήστε με σαφήνεια πώς να συνεισφέρετε**, χρησιμοποιώντας [το αρχείο CONTRIBUTING](../starting-a-project/#γράφοντας-τις-κατευθυντήριες-γραμμές-συνεισφοράς-σας) και διατηρώντας τα θέματά σας ενημερωμένα.
-* **Καλά πρώτα θέματα**: Για να βοηθήσετε τους νέους συνεισφέροντες να ξεκινήσουν, σκεφτείτε ρητά [την επισήμανση θεμάτων που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα θέματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας τις χρήσιμες συνεισφορές και μειώνοντας τις τριβές από τους χρήστες που αντιμετωπίζουν θέματα που είναι πολύ δύσκολα για το επίπεδό τους.
+* **Καλά πρώτα θέματα**: Για να βοηθήσετε τους νέους συνεισφέροντες να ξεκινήσουν, σκεφτείτε ρητά [την επισήμανση θεμάτων που είναι αρκετά απλά για να τα αντιμετωπίσουν οι αρχάριοι](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). Στη συνέχεια, το GitHub θα εμφανίσει αυτά τα θέματα σε διάφορα σημεία της πλατφόρμας, αυξάνοντας τις χρήσιμες συνεισφορές και μειώνοντας τις τριβές από τους χρήστες που αντιμετωπίζουν θέματα που είναι πολύ δύσκολα για το επίπεδό τους.
 
 [Η έρευνα του GitHub για τον ανοικτό κώδικα του 2017](http://opensourcesurvey.org/2017/) έδειξε ότι η ελλιπής ή συγκεχυμένη τεκμηρίωση είναι το μεγαλύτερο πρόβλημα για τους χρήστες ανοικτού κώδικα. Η καλή τεκμηρίωση προσκαλεί τους ανθρώπους να αλληλεπιδράσουν με το πρότζεκτ σας. Τελικά, κάποιος θα ανοίξει ένα ζήτημα ή ένα αίτημα. Χρησιμοποιήστε αυτές τις αλληλεπιδράσεις ως ευκαιρίες για να τους μετακινήσετε προς τα κάτω στο χωνί.
 
@@ -167,7 +167,7 @@ related:
 
 * **Δώστε σε κάθε συνεισφέροντα πρόσβαση για commit.** Ο @felixge διαπίστωσε ότι αυτό έκανε τους ανθρώπους [πιο ενθουσιασμένους να γυαλίζουν τις διορθώσεις τους](https://felixge.de/2013/03/11/the-pull-request-hack.html), και βρήκε ακόμα και νέους συντηρητές για πρότζεκτ στα οποία δεν είχε δουλέψει για λίγο καιρό.
 
-* Αν το πρότζεκτ σας είναι στο GitHub, **μεταφέρετε το πρότζκετ σας από τον προσωπικό σας λογαριασμό σε έναν [Οργανισμό](https://help.github.com/articles/creating-a-new-organization-account/)** και προσθέστε τουλάχιστον έναν εφεδρικό διαχειριστή. Οι οργανισμοί διευκολύνουν την εργασία σε πρότζεκτς με εξωτερικούς συνεργάτες.
+* Αν το πρότζεκτ σας είναι στο GitHub, **μεταφέρετε το πρότζκετ σας από τον προσωπικό σας λογαριασμό σε έναν [Οργανισμό](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** και προσθέστε τουλάχιστον έναν εφεδρικό διαχειριστή. Οι οργανισμοί διευκολύνουν την εργασία σε πρότζεκτς με εξωτερικούς συνεργάτες.
 
 Η πραγματικότητα είναι ότι [τα περισσότερα πρότζεκτς έχουν μόνο](https://peerj.com/preprints/1233/) έναν ή δύο συντηρητές που κάνουν την περισσότερη δουλειά. Όσο μεγαλύτερο είναι το πρότζεκτ σας και όσο μεγαλύτερη είναι η κοινότητά σας, τόσο πιο εύκολο είναι να βρείτε βοήθεια.
 
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index c81325f7a05..49d1c2dc86c 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -437,7 +437,7 @@ related:
 
 Πριν ανοίξετε ένα θέμα ή ένα αίτημα έλξης, ελέγξτε τα έγγραφα συνεισφοράς του έργου (συνήθως ένα αρχείο που ονομάζεται ΣΥΝΔΡΟΜΗ ή στο README), για να δείτε αν πρέπει να συμπεριλάβετε κάτι συγκεκριμένο. Για παράδειγμα, μπορεί να σας ζητούν να ακολουθήσετε ένα πρότυπο ή να απαιτείται η χρήση δοκιμών.
 
-Αν θέλετε να κάνετε μια ουσιαστική συνεισφορά, ανοίξτε ένα θέμα για να ρωτήσετε πριν εργαστείτε πάνω σε αυτό. Είναι χρήσιμο να παρακολουθείτε το έργο για λίγο (στο GitHub, [μπορείτε να κάνετε κλικ στο "Watch"](https://help.github.com/articles/watching-repositories/) για να ενημερώνεστε για όλες τις συζητήσεις), και να γνωρίσετε τα μέλη της κοινότητας, πριν κάνετε εργασία που μπορεί να μην γίνει αποδεκτή.
+Αν θέλετε να κάνετε μια ουσιαστική συνεισφορά, ανοίξτε ένα θέμα για να ρωτήσετε πριν εργαστείτε πάνω σε αυτό. Είναι χρήσιμο να παρακολουθείτε το έργο για λίγο (στο GitHub, [μπορείτε να κάνετε κλικ στο "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) για να ενημερώνεστε για όλες τις συζητήσεις), και να γνωρίσετε τα μέλη της κοινότητας, πριν κάνετε εργασία που μπορεί να μην γίνει αποδεκτή.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -472,7 +472,7 @@ related:
 
 Αν το έργο βρίσκεται στο GitHub, δείτε πώς μπορείτε να υποβάλετε ένα pull request:
 
-* **[Κάντε fork το πρότζεκτ](https://guides.github.com/activities/forking/)** και κλωνοποιήστε το τοπικά. Συνδέστε το τοπικό σας με το αρχικό "upstream" αποθετήριο προσθέτοντάς το ως απομακρυσμένο. Τραβήξτε συχνά αλλαγές από το "upstream" ώστε να παραμένετε ενημερωμένοι, ώστε όταν υποβάλετε το pull request σας, οι συγκρούσεις συγχώνευσης να είναι λιγότερο πιθανές. (Δείτε πιο λεπτομερείς οδηγίες [εδώ](https://help.github.com/articles/syncing-a-fork/).)
+* **[Κάντε fork το πρότζεκτ](https://guides.github.com/activities/forking/)** και κλωνοποιήστε το τοπικά. Συνδέστε το τοπικό σας με το αρχικό "upstream" αποθετήριο προσθέτοντάς το ως απομακρυσμένο. Τραβήξτε συχνά αλλαγές από το "upstream" ώστε να παραμένετε ενημερωμένοι, ώστε όταν υποβάλετε το pull request σας, οι συγκρούσεις συγχώνευσης να είναι λιγότερο πιθανές. (Δείτε πιο λεπτομερείς οδηγίες [εδώ](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Δημιουργήστε έναν κλάδο](https://guides.github.com/introduction/flow/)** για τις επεξεργασίες σας.
 * **Αναφέρετε οποιαδήποτε σχετικά θέματα** ή υποστηρικτική τεκμηρίωση στο PR σας (για παράδειγμα, "Κλείνει το #37.")
 * **Περιλάβετε στιγμιότυπα οθόνης του πριν και του μετά** αν οι αλλαγές σας περιλαμβάνουν διαφορές στην HTML/CSS. Σύρετε και αφήστε τις εικόνες στο σώμα του αιτήματος έλξης σας.
diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
index 565ae99b8b8..b1bad23b5aa 100644
--- a/_articles/el/leadership-and-governance.md
+++ b/_articles/el/leadership-and-governance.md
@@ -73,7 +73,7 @@ related:
 
 Εργαλεία όπως το [Vossibility](https://github.com/icecrime/vossibility-stack) μπορούν να σας βοηθήσουν να παρακολουθείτε δημόσια ποιος συνεισφέρει (ή δεν συνεισφέρει) στο πρότζεκτ. Η τεκμηρίωση αυτών των πληροφοριών αποφεύγει την αντίληψη της κοινότητας ότι οι συντηρητές είναι μια κλίκα που παίρνει τις αποφάσεις της ιδιωτικά.
 
-Τέλος, αν το πρότζεκτ σας βρίσκεται στο GitHub, εξετάστε το ενδεχόμενο να μεταφέρετε το πρότζεκτ σας από τον προσωπικό σας λογαριασμό σε έναν Οργανισμό και να προσθέσετε τουλάχιστον έναν εφεδρικό διαχειριστή. Οι [Οργανισμοί του GitHub](https://help.github.com/articles/creating-a-new-organization-account/) διευκολύνουν τη διαχείριση των δικαιωμάτων και των πολλαπλών αποθετηρίων και προστατεύουν την κληρονομιά του πρότζεκτ σας μέσω της [κοινής ιδιοκτησίας](../building-community/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας).
+Τέλος, αν το πρότζεκτ σας βρίσκεται στο GitHub, εξετάστε το ενδεχόμενο να μεταφέρετε το πρότζεκτ σας από τον προσωπικό σας λογαριασμό σε έναν Οργανισμό και να προσθέσετε τουλάχιστον έναν εφεδρικό διαχειριστή. Οι [Οργανισμοί του GitHub](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) διευκολύνουν τη διαχείριση των δικαιωμάτων και των πολλαπλών αποθετηρίων και προστατεύουν την κληρονομιά του πρότζεκτ σας μέσω της [κοινής ιδιοκτησίας](../building-community/#μοιραστείτε-την-ιδιοκτησία-του-πρότζεκτ-σας).
 
 ## Πότε θα πρέπει να δώσω σε κάποιον πρόσβαση στα commits;
 
@@ -81,7 +81,7 @@ related:
 
 Από την άλλη πλευρά, ειδικά για μεγαλύτερα, πιο σύνθετα πρότζεκτ, μπορεί να θέλετε να δώσετε πρόσβαση στη δέσμευση μόνο σε άτομα που έχουν αποδείξει τη δέσμευσή τους. Δεν υπάρχει ένας μόνο σωστός τρόπος - κάντε αυτό που σας κάνει να αισθάνεστε πιο άνετα!
 
-Αν το πρότζεκτ σας βρίσκεται στο GitHub, μπορείτε να χρησιμοποιήσετε το [protected branches](https://help.github.com/articles/about-protected-branches/) για να διαχειριστείτε ποιος μπορεί να προωθήσει σε ένα συγκεκριμένο κλάδο και υπό ποιες συνθήκες.
+Αν το πρότζεκτ σας βρίσκεται στο GitHub, μπορείτε να χρησιμοποιήσετε το [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) για να διαχειριστείτε ποιος μπορεί να προωθήσει σε ένα συγκεκριμένο κλάδο και υπό ποιες συνθήκες.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index 29d7ed72b6b..a5d368a08b4 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -28,7 +28,7 @@ related:
 
 ## Είναι τα δημόσια πρότζεκτ GitHub ανοιχτού κώδικα;
 
-Όταν [δημιουργείτε ένα νέο πρότζεκτ](https://help.github.com/articles/creating-a-new-repository/) στο GitHub, έχετε την επιλογή να κάνετε το αποθετήριο **ιδιωτικό** ή **δημόσιο**.
+Όταν [δημιουργείτε ένα νέο πρότζεκτ](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) στο GitHub, έχετε την επιλογή να κάνετε το αποθετήριο **ιδιωτικό** ή **δημόσιο**.
 
 ![Δημιουργία αποθετηρίου](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ related:
 
 Οι [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/).
+Όταν δημιουργείτε ένα νέο πρότζεκτ στο GitHub, θα σας ζητηθεί [να προσθέσετε μια άδεια](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ related:
 
 ## Χρειάζεται το πρότζεκτ μου μια πρόσθετη συμφωνία συνεισφοράς;
 
-Μάλλον όχι. Για τη συντριπτική πλειονότητα των πρότζεκτ ανοικτού κώδικα, μια άδεια ανοικτού κώδικα χρησιμεύει σιωπηρά τόσο ως η εισερχόμενη (από τους συνεισφέροντες) όσο και ως η εξερχόμενη (προς άλλους συνεισφέροντες και χρήστες) άδεια. Εάν το πρότζεκτ σας βρίσκεται στο GitHub, οι όροι χρήσης του GitHub καθιστούν το "inbound=outbound" τη [ρητή προεπιλογή](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Μάλλον όχι. Για τη συντριπτική πλειονότητα των πρότζεκτ ανοικτού κώδικα, μια άδεια ανοικτού κώδικα χρησιμεύει σιωπηρά τόσο ως η εισερχόμενη (από τους συνεισφέροντες) όσο και ως η εξερχόμενη (προς άλλους συνεισφέροντες και χρήστες) άδεια. Εάν το πρότζεκτ σας βρίσκεται στο GitHub, οι όροι χρήσης του GitHub καθιστούν το "inbound=outbound" τη [ρητή προεπιλογή](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Μια πρόσθετη συμφωνία συνεισφέροντος -- συχνά αποκαλούμενη Συμφωνία άδειας χρήσης συνεισφέροντος (CLA) -- μπορεί να δημιουργήσει διοικητική εργασία για τους συντηρητές του έργου. Το πόση εργασία προσθέτει μια συμφωνία εξαρτάται από το πρότζεκτ και την εφαρμογή. Μια απλή συμφωνία μπορεί να απαιτεί από τους συνεισφέροντες να επιβεβαιώνουν, με ένα κλικ, ότι έχουν τα απαραίτητα δικαιώματα για να συνεισφέρουν σύμφωνα με την άδεια χρήσης ανοικτού κώδικα του έργου. Μια πιο περίπλοκη συμφωνία μπορεί να απαιτεί νομικό έλεγχο και υπογραφή από τους εργοδότες των συνεισφερόντων.
 
diff --git a/_articles/el/metrics.md b/_articles/el/metrics.md
index ab1ff2adf6a..54cca08eccb 100644
--- a/_articles/el/metrics.md
+++ b/_articles/el/metrics.md
@@ -37,7 +37,7 @@ related:
 
 ![Διάγραμμα κυκλοφορίας](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Εάν το πρότζεκτ σας φιλοξενείται στο GitHub, [μπορείτε να δείτε](https://help.github.com/articles/about-repository-graphs/#traffic) πόσοι άνθρωποι μπαίνουν στο πρότζεκτ σας και από πού προέρχονται. Από τη σελίδα του έργου σας, κάντε κλικ στην επιλογή "Insights" και στη συνέχεια στην επιλογή "Traffic". Σε αυτή τη σελίδα, μπορείτε να δείτε: "Το πρότζεκτ σας":
+Εάν το πρότζεκτ σας φιλοξενείται στο GitHub, [μπορείτε να δείτε](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) πόσοι άνθρωποι μπαίνουν στο πρότζεκτ σας και από πού προέρχονται. Από τη σελίδα του έργου σας, κάντε κλικ στην επιλογή "Insights" και στη συνέχεια στην επιλογή "Traffic". Σε αυτή τη σελίδα, μπορείτε να δείτε: "Το πρότζεκτ σας":
 
 * **Συνολικές προβολές σελίδων:** Σας λέει πόσες φορές προβλήθηκε το πρότζεκτ σας
 
@@ -47,7 +47,7 @@ related:
 
 * **Δημοφιλές περιεχόμενο:** Σας λέει πού πηγαίνουν οι επισκέπτες στο πρότζεκτ σας, κατανεμημένο σε προβολές σελίδων και μοναδικούς επισκέπτες.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) μπορεί επίσης να βοηθήσει στην παροχή ενός βασικού μέτρου δημοτικότητας. Αν και τα αστέρια του GitHub δεν συσχετίζονται απαραίτητα με τις λήψεις και τη χρήση, μπορούν να σας δείξουν πόσοι άνθρωποι λαμβάνουν γνώση της εργασίας σας.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) μπορεί επίσης να βοηθήσει στην παροχή ενός βασικού μέτρου δημοτικότητας. Αν και τα αστέρια του GitHub δεν συσχετίζονται απαραίτητα με τις λήψεις και τη χρήση, μπορούν να σας δείξουν πόσοι άνθρωποι λαμβάνουν γνώση της εργασίας σας.
 
 Μπορεί επίσης να θέλετε να [παρακολουθείτε την ανιχνευσιμότητα σε συγκεκριμένα μέρη](https://opensource.com/business/16/6/pirate-metrics): για παράδειγμα, το Google PageRank, την επισκεψιμότητα παραπομπών από τον ιστότοπο του έργου σας ή παραπομπές από άλλα πρότζεκτ ή ιστότοπους ανοικτού κώδικα.
 
diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
index 6cac5028fea..4e201f9ad94 100644
--- a/_articles/el/starting-a-project.md
+++ b/_articles/el/starting-a-project.md
@@ -106,9 +106,9 @@ related:
 
 Ανεξάρτητα από το στάδιο στο οποίο θα αποφασίσετε να ανοίξετε το πρότζεκτ σας, κάθε πρότζεκτ θα πρέπει να περιλαμβάνει την ακόλουθη τεκμηρίωση:
 
-* [Άδεια χρήσης ανοικτού κώδικα](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)
-* [Κανόνες για τους συνεισφέροντες](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Άδεια χρήσης ανοικτού κώδικα](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Κανόνες για τους συνεισφέροντες](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Κώδικας δεοντολογίας](../code-of-conduct/)
 
 Ως συντηρητής, αυτά τα στοιχεία θα σας βοηθήσουν να επικοινωνήσετε τις προσδοκίες, να διαχειριστείτε τις συνεισφορές και να προστατεύσετε τα νομικά δικαιώματα όλων (συμπεριλαμβανομένων των δικών σας). Αυξάνουν σημαντικά τις πιθανότητές σας να έχετε μια θετική εμπειρία.
@@ -182,7 +182,7 @@ related:
 
 Για περισσότερη βοήθεια σχετικά με τη σύνταξη του αρχείου CONTRIBUTING, δείτε το [πρότυπο οδηγού συνεισφοράς](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) του @nayafia ή το ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) του @mozilla.
 
-Συνδέστε το αρχείο CONTRIBUTING από το README, ώστε να το βλέπουν περισσότεροι άνθρωποι. Εάν [τοποθετήσετε το αρχείο CONTRIBUTING στο αποθετήριο του έργου σας](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), το GitHub θα συνδέει αυτόματα το αρχείο σας όταν ένας συνεργάτης δημιουργεί ένα ζήτημα ή ανοίγει ένα pull request.
+Συνδέστε το αρχείο CONTRIBUTING από το README, ώστε να το βλέπουν περισσότεροι άνθρωποι. Εάν [τοποθετήσετε το αρχείο CONTRIBUTING στο αποθετήριο του έργου σας](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), το GitHub θα συνδέει αυτόματα το αρχείο σας όταν ένας συνεργάτης δημιουργεί ένα ζήτημα ή ανοίγει ένα pull request.
 
 ![Οδηγίες συνεισφοράς](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ related:
 
 ## Ο κατάλογος ελέγχου πριν από την έναρξη
 
-Είστε έτοιμοι να ανοίξετε το πρότζεκτ σας; Ακολουθεί ένας κατάλογος ελέγχου για να σας βοηθήσει. Έχετε τσεκάρει όλα τα κουτάκια; Είστε έτοιμοι να ξεκινήσετε! [Κάντε κλικ στο "publish"](https://help.github.com/articles/making-a-private-repository-public/) και χτυπήστε τον εαυτό σας στην πλάτη.
+Είστε έτοιμοι να ανοίξετε το πρότζεκτ σας; Ακολουθεί ένας κατάλογος ελέγχου για να σας βοηθήσει. Έχετε τσεκάρει όλα τα κουτάκια; Είστε έτοιμοι να ξεκινήσετε! [Κάντε κλικ στο "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) και χτυπήστε τον εαυτό σας στην πλάτη.
 
 **Έγγραφα**
 
diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md
index c8aee16a1d5..1c84265b6f7 100644
--- a/_articles/es/best-practices.md
+++ b/_articles/es/best-practices.md
@@ -214,7 +214,7 @@ Una de las maneras m&aacute;s importantes de automatizar tu proyecto es realizan
 El testing ayuda a los contribuyentes a sentirse seguros de que no romper&aacute;n nada. Tambi&eacute;n facilitan la revisi&oacute;n y aceptaci&oacute;n de contribuciones r&aacute;pidamente. Cuanto m&aacute;s receptivo seas, m&aacute;s comprometida podr&aacute; ser tu comunidad.
 
 Configura los tests autom&aacute;ticos que se ejecutar&aacute;n en todas las contribuciones entrantes y aseg&uacute;rate de que puedan ser ejecutados localmente por los contribuyentes. Requiere que todas las contribuciones de c&oacute;digo pasen por los tests antes de que puedan ser enviadas. Ayudar&aacute; a establecer un est&aacute;ndar m&iacute;nimo de calidad para todas las solicitudes.
-[Chequeos de estado requerido](https://help.github.com/articles/about-required-status-checks/) en GitHub pueden ayudar a asegurar que ning&uacute;n cambio se fusione sin pasar primero por los tests.
+[Chequeos de estado requerido](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) en GitHub pueden ayudar a asegurar que ning&uacute;n cambio se fusione sin pasar primero por los tests.
 
 Si agregas testing, aseg&uacute;rate de explicar c&oacute;mo funcionan en su archivo CONTRIBUTING.
 
diff --git a/_articles/es/building-community.md b/_articles/es/building-community.md
index fe289f559de..1636408b8bc 100644
--- a/_articles/es/building-community.md
+++ b/_articles/es/building-community.md
@@ -168,7 +168,7 @@ Observa si puedes encontrar maneras de compartir la propiedad de tu comunidad ta
 * **Da a cada colaborador permiso para hacer commit.** @felixge encontr&oacute; con esto que las personas [se entusiasmaran por pulir sus parches](https://felixge.de/2013/03/11/the-pull-request-hack.html), e incluso encontr&oacute; nuevas personas para mantener proyectos en los que no hab&iacute;a trabajado hace tiempo.
 
 
-* Si tu proyecto est&aacute; alojado en GitHub, **mueve tu proyecto desde tu cuenta personal hacia una [Organizaci&oacute;n](https://help.github.com/articles/creating-a-new-organization-account/)** y agrega al menos un administrador de respaldo. Las Organizaciones hacen que sea m&aacute;s f&aacute;cil trabajar en proyectos con colaboradores externos.
+* Si tu proyecto est&aacute; alojado en GitHub, **mueve tu proyecto desde tu cuenta personal hacia una [Organizaci&oacute;n](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** y agrega al menos un administrador de respaldo. Las Organizaciones hacen que sea m&aacute;s f&aacute;cil trabajar en proyectos con colaboradores externos.
 
 La realidad es que [la mayor&iacute;a de los proyectos solo tienen](https://peerj.com/preprints/1233/) una o dos personas que lo mantengan y que hacen la mayor&iacute;a del trabajo. Mientras m&aacute;s grande sea tu proyecto, y mientras m&aacute;s grande sea tu comunidad, m&aacute;s f&aacute;cil es encontrar ayuda.
 
diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index 45fd5219c11..e6de5cafd38 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -433,7 +433,7 @@ Si no puedes encontrar tu idea en ning&uacute;n otro lado, est&aacute;s listo pa
 
 Antes de abrir un problema o un pull request, verifica los documentos de verificaci&oacute;n del proyecto (com&uacute;nmente es un archivo que se llama CONTRIBUTING), para ver si se necesitan incluir algo espec&iacute;fico, puede ser que soliciten que respetes un modelo, o requerir que utilices pruebas.
 
-Si quieres hacer una contribuci&oacute;n sustancial, abre un problema para preguntar antes de ponerte a trabajar en ello. Es de gran ayuda observar el proyecto por un tiempo (en GitHub, [puedes hacer click en "Watch"](https://help.github.com/articles/watching-repositories/) para ser notificado de todas las conversaciones), y conocer a los miembros de la comunidad, antes de realizar trabajo alguno que pueda no ser aceptado.
+Si quieres hacer una contribuci&oacute;n sustancial, abre un problema para preguntar antes de ponerte a trabajar en ello. Es de gran ayuda observar el proyecto por un tiempo (en GitHub, [puedes hacer click en "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) para ser notificado de todas las conversaciones), y conocer a los miembros de la comunidad, antes de realizar trabajo alguno que pueda no ser aceptado.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -468,7 +468,7 @@ Un pull request no representa trabajo terminado. Usualmente es mejor abrir un pu
 
 Si el proyecto est&aacute; alojado en GITHUB, ac&aacute; te explicamos los pasos para enviar un pull request:
 
-* **[Abre un fork del repositorio](https://guides.github.com/activities/forking/)** y haz un clon local. Conecta tu repositorio local con el repositorio "superior" original agreg&aacute;ndolo como remoto. Descarga los cambios desde el repositorio superior con frecuencia de manera que puedas mantener al d&iacute;a, de forma que cuando tu env&iacute;es tu pull request, sea menos probable que haya conflictos. (ver m&aacute;s instrucciones detalladas [aqu&iacute;](https://help.github.com/articles/syncing-a-fork/).)
+* **[Abre un fork del repositorio](https://guides.github.com/activities/forking/)** y haz un clon local. Conecta tu repositorio local con el repositorio "superior" original agreg&aacute;ndolo como remoto. Descarga los cambios desde el repositorio superior con frecuencia de manera que puedas mantener al d&iacute;a, de forma que cuando tu env&iacute;es tu pull request, sea menos probable que haya conflictos. (ver m&aacute;s instrucciones detalladas [aqu&iacute;](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Crea una rama](https://guides.github.com/introduction/flow/)** para tus ediciones.
 * **Haz referencia a cualquier problema relevante** o documentaci&oacute;n de soporte en tu PR (por ejemplo "Cierra #37.")
 * **Incluye capturas de pantalla del antes y del despu&eacute;s** si tus cambios incluyen diferencias en el HTML o CSS. Arrastra y suelta las im&aacute;genes en el cuerpo de tu pull request.
diff --git a/_articles/es/leadership-and-governance.md b/_articles/es/leadership-and-governance.md
index a44c85beef5..774404d4277 100644
--- a/_articles/es/leadership-and-governance.md
+++ b/_articles/es/leadership-and-governance.md
@@ -73,7 +73,7 @@ Una vez que haya establecido roles de liderazgo, ¡no olvides documentar c&oacut
 
 Herramientas como [Vossibility](https://github.com/icecrime/vossibility-stack) puede ayudarte a hacer un seguimiento p&uacute;blico de qui&eacute;n (o no) est&aacute; haciendo contribuciones al proyecto. Documentar esta informaci&oacute;n evita la percepci&oacute;n de la comunidad de que los mantenedores son un grupo que toma sus decisiones en privado.
 
-Por &uacute;ltimo, si su proyecto est&aacute; en GitHub, considere la posibilidad de mover su proyecto de su cuenta personal a una organizaci&oacute;n y agregar al menos un administrador de copias de seguridad. [Las organizaciones GitHub](https://help.github.com/articles/creating-a-new-organization-account/) facilitan la administraci&oacute;n de permisos y m&uacute;ltiples repositorios y protegen el legado de su proyecto mediante [la propiedad compartida](../building-community/#comparte-la-propiedad-de-tu-proyecto).
+Por &uacute;ltimo, si su proyecto est&aacute; en GitHub, considere la posibilidad de mover su proyecto de su cuenta personal a una organizaci&oacute;n y agregar al menos un administrador de copias de seguridad. [Las organizaciones GitHub](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) facilitan la administraci&oacute;n de permisos y m&uacute;ltiples repositorios y protegen el legado de su proyecto mediante [la propiedad compartida](../building-community/#comparte-la-propiedad-de-tu-proyecto).
 
 ## &iquest;Cu&aacute;ndo le puedo dar acceso a hacer commits a alguien?
 
@@ -81,7 +81,7 @@ Algunas personas piensan que debe dar acceso de commits a todos los que hacen un
 
 Por otro lado, especialmente para proyectos m&aacute;s grandes y complejos, es posible que desee dar s&oacute;lo el acceso de commit a las personas que han demostrado su compromiso. No hay una manera correcta de hacerlo - ¡Haz lo que te parezca m&aacute;s c&oacute;modo!
 
-Si tu proyecto est&aacute; en GitHub, pod&eacute;s utilizar [ramas protegidas](https://help.github.com/articles/about-protected-branches/) para administrar qui&eacute;n puede enviar a una rama en particular y bajo qu&eacute; circunstancias.
+Si tu proyecto est&aacute; en GitHub, pod&eacute;s utilizar [ramas protegidas](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) para administrar qui&eacute;n puede enviar a una rama en particular y bajo qu&eacute; circunstancias.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 24746980bc5..0227f94dd86 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -28,7 +28,7 @@ Finalmente, tu proyecto puede tener dependencias con requisitos de licencia que
 
 ## ¿Son p&uacute;blicos los proyectos de c&oacute;digo abierto de GitHub?
 
-Cuando t&uacute; [creas un nuevo proyecto](https://help.github.com/articles/creating-a-new-repository/) en GitHub, tienes la opci&oacute;n de hacerlo **privado** o **p&uacute;blico**.
+Cuando t&uacute; [creas un nuevo proyecto](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) en GitHub, tienes la opci&oacute;n de hacerlo **privado** o **p&uacute;blico**.
 
 ![crear repositorio](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Tienes suerte, porque hoy, las licencias de c&oacute;digo abierto est&aacute;n e
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), y [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) son las licencias de c&oacute;digo abierto m&aacute;s populares, pero tambi&eacute;n tienes otras opciones para elegir. Puedes encontrar un texto completo sobre estas licencias, e instrucciones de uso de las mismas en [choosealicense.com](https://choosealicense.com/).
 
-Cuando crees un nuevo proyecto en GitHub, se te [pedir&aacute; que agregues una licencia](https://help.github.com/articles/open-source-licensing/).
+Cuando crees un nuevo proyecto en GitHub, se te [pedir&aacute; que agregues una licencia](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -89,7 +89,7 @@ De manera alternativa, puedes tener colaboradores que est&eacute;n de acuerdo po
 
 ## ¿Necesita mi proyecto un acuerdo adicional de colaboradores?
 
-Probablemente no. En la mayor&iacute;a de los proyectos de c&oacute;digo abierto, una licencia de c&oacute;digo abierto sirve impl&iacute;citamente de licencia tanto para el interior (colaboradores) como para el exterior (a otros colaboradores y usuarios). Si tu proyecto se encuentra en GitHub, los T&eacute;rminos de Servicio de GitHub la hacen "entrante=saliente" la [expl&iacute;cita por defecto](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Probablemente no. En la mayor&iacute;a de los proyectos de c&oacute;digo abierto, una licencia de c&oacute;digo abierto sirve impl&iacute;citamente de licencia tanto para el interior (colaboradores) como para el exterior (a otros colaboradores y usuarios). Si tu proyecto se encuentra en GitHub, los T&eacute;rminos de Servicio de GitHub la hacen "entrante=saliente" la [expl&iacute;cita por defecto](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Un acuerdo adicional de colaboradores – a menudo llamado Acuerdo de Licencia de colaboradores (en ingl&eacute;s, CLA) – puede crear trabajo administrativo para mantenedores de proyecto. La cantidad de trabajo que suma un acuerdo depende del proyecto y su implementaci&oacute;n. Un acuerdo simple puede requerir que los colaboradores confirmen, con un clic, que tienen los derechos necesarios para contribuir bajo la licencia de c&oacute;digo abierto del proyecto. Un acuerdo m&aacute;s complicado, requerir&aacute; revisi&oacute;n legal y la aprobaci&oacute;n de los empleadores del contribuyente.
 
diff --git a/_articles/es/metrics.md b/_articles/es/metrics.md
index 970b4030785..d71b3ec0bc1 100644
--- a/_articles/es/metrics.md
+++ b/_articles/es/metrics.md
@@ -37,7 +37,7 @@ Antes de que alguien pueda usar o contribuir a tu proyecto, quiz&aacute;s necesi
 
 ![traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Si tu proyecto est&aacute; hosteado en GitHub, [puedes ver](https://help.github.com/articles/about-repository-graphs/#traffic) cu&aacute;ntas personas lo visitan, y de d&oacute;nde vienen. En la p&aacute;gina de tu proyecto haz click en "Graphs", y luego "Traffic". En esta p&aacute;gina puedes ver:
+Si tu proyecto est&aacute; hosteado en GitHub, [puedes ver](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) cu&aacute;ntas personas lo visitan, y de d&oacute;nde vienen. En la p&aacute;gina de tu proyecto haz click en "Graphs", y luego "Traffic". En esta p&aacute;gina puedes ver:
 
 * **Total de vistas:** Informa la cantidad de veces que tu p&aacute;gina fue vista
 
@@ -47,7 +47,7 @@ Si tu proyecto est&aacute; hosteado en GitHub, [puedes ver](https://help.github.
 
 * **Contenido popular:** Te informa sobre las partes del proyecto que la gente m&aacute;s visita.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) puede brindarte una l&iacute;nea base para medir popularidad. No necesariamente tiene que ver con uso o cantidad de descargas, si no m&aacute;s bien según la cantidad de notoriedad de tu proyecto.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) puede brindarte una l&iacute;nea base para medir popularidad. No necesariamente tiene que ver con uso o cantidad de descargas, si no m&aacute;s bien según la cantidad de notoriedad de tu proyecto.
 
 Quiz&aacute;s tambi&eacute;n quieras [rastrear la forma que te descubren desde lugares espec&iacute;ficos](https://opensource.com/business/16/6/pirate-metrics): por ejemplo, Google PageRank, tr&aacute;fico que hace referencia a tu p&aacute;gina web del proyecto, o referencias desde otros proyectos.
 
diff --git a/_articles/es/starting-a-project.md b/_articles/es/starting-a-project.md
index bb40cf05b4f..5ab99cc2f19 100644
--- a/_articles/es/starting-a-project.md
+++ b/_articles/es/starting-a-project.md
@@ -113,9 +113,9 @@ Generalmente, puedes abrir el c&oacute;digo de tu proyecto cuando te sientas c&o
 
 No importa en qu&eacute; etapa decidas hacerlo, cada proyecto debe incluir la siguiente documentaci&oacute;n.
 
-* [Licencia de C&oacute;digo Abierto](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)
-* [Pautas para contribuir](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Licencia de C&oacute;digo Abierto](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Pautas para contribuir](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [C&oacute;digo de conducta](../code-of-conduct/)
 
 Como encargado de mantenimiento, estos componentes ayudar&aacute;n a comunicar tus deseos, manejar tus contribuciones y proteger los derechos legales de cada uno (incluy&eacute;ndote). Incrementan significativamente tus posibilidades de tener una experiencia positiva.
@@ -189,7 +189,7 @@ Con el tiempo, quiz&aacute;s debas agregar otras "preguntas frecuentes" a tu arc
 
 Para m&aacute;s informaci&oacute;n sobre este tema, puedes acceder a @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) o @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Vincula tu CONTRIBUTING desde tu README, as&iacute; m&aacute;s personas pueden verlo.Si tu [colocas el archivo en tu repositorio](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub autom&aacute;ticamente lo vincular&aacute; cuando un contribuyente cree un issue o abra un pull request.
+Vincula tu CONTRIBUTING desde tu README, as&iacute; m&aacute;s personas pueden verlo.Si tu [colocas el archivo en tu repositorio](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub autom&aacute;ticamente lo vincular&aacute; cuando un contribuyente cree un issue o abra un pull request.
 
 ![Pautas para contribuir](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -262,7 +262,7 @@ No es necesario escribir una "gu&iacute;a de estilo" para tus proyectos cuando r
 
 ## Tu checklist a armar previamente al lanzamiento del proyecto
 
-Est&aacute;s listo para iniciar tu propio proyecto de C&oacute;digo Abierto. Aqu&iacute; dejamos un checklist que puede ayudar. &iexcl;Una vez marcadas todas las casillas estás listo para continuar! [Clickea "publish"](https://help.github.com/articles/making-a-private-repository-public/).
+Est&aacute;s listo para iniciar tu propio proyecto de C&oacute;digo Abierto. Aqu&iacute; dejamos un checklist que puede ayudar. &iexcl;Una vez marcadas todas las casillas estás listo para continuar! [Clickea "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility).
 
 **Documentaci&oacute;n**
 
diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index 8a22e65aa06..ea08d7c3727 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -165,7 +165,7 @@ related:
 
 اگر می‌خواهید که دیگران به شما کمک کنند، از آن‌ها درخواست کنید.
 
-راهی برای جذب مشارکت‌کنندگان این است که کارها را از نظر سختی درجه‌بندی کنید و [کارهای ساده را به مبتدی‌ها بسپرید](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). سپس GitHub این موضوعات را در فضاهای مختلف خودش به نمایش می‌گذارد و باعث افزایش دیده شدن آن‌ها می‌شود.
+راهی برای جذب مشارکت‌کنندگان این است که کارها را از نظر سختی درجه‌بندی کنید و [کارهای ساده را به مبتدی‌ها بسپرید](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). سپس GitHub این موضوعات را در فضاهای مختلف خودش به نمایش می‌گذارد و باعث افزایش دیده شدن آن‌ها می‌شود.
 
 وقتی مشاهده کردید که مشارکت‌کنندگان جدید به صورت مکرر همکاری می‌کنند، با دادن مسئولیت‌های بیشتر، آن‌ها را تصدیق کنید و به رسمیت بشناسید. مشخص کنید که چگونه دیگران می‌توانند در صورت اشتیاق به جایگاه‌های رهبری دست یابند.
 
@@ -215,7 +215,7 @@ related:
 تست‌ها به مشارکت‌کنندگان کمک می‌کند تا اطمینان داشته باشند که چیزی را خراب نمی کنند. تست‌ها،همچنین بررسی و پذیرش سریع مشارکت‌ها را برای شما آسان می‌کند.
 هر چقدر از خود علاقه‌ی بیشتری نمایش دهید و مشتاق‌تر باشید،اجتماع شما مشارکت بیشتری خواهد داشت.
 
-تست‌های خودکاری را طراحی کنید که برای همه مشارکت‌های آتی اجرا شود و اطمینان حاصل کنید که تست‌های شما به راحتی توسط مشارکت‌کنندگان قابل اجرا باشند. قبول کردن درخواست‌های مشارکت در کدها را ملزم به قبول شدن در آن تست بکنید. با این کار، حداقل استاندارد کیفیتی را برای همه‌ی درخواست‌ها تعیین می‌کنید. [با بررسی وضعیت](https://help.github.com/articles/about-required-status-checks/) در GitHub می‌توانید اطمینان حاصل کنید که بدون گذراندن تست‌های شما اجازه‌ی هیچ گونه تغییری داده نمی‌شود.
+تست‌های خودکاری را طراحی کنید که برای همه مشارکت‌های آتی اجرا شود و اطمینان حاصل کنید که تست‌های شما به راحتی توسط مشارکت‌کنندگان قابل اجرا باشند. قبول کردن درخواست‌های مشارکت در کدها را ملزم به قبول شدن در آن تست بکنید. با این کار، حداقل استاندارد کیفیتی را برای همه‌ی درخواست‌ها تعیین می‌کنید. [با بررسی وضعیت](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) در GitHub می‌توانید اطمینان حاصل کنید که بدون گذراندن تست‌های شما اجازه‌ی هیچ گونه تغییری داده نمی‌شود.
 
 اگر تست‌هایی اضافه کردید، حتماً نحوه‌ی کارکرد آن‌ها را در فایل «CONTRIBUTING» (مشارکت) خود توضیح دهید.
 
diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index 15cc1d0c63d..9fa52eaa80b 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -29,7 +29,7 @@ related:
 * **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#نوشتن-راهنمای-مشارکت) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد.
 * **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#نوشتن-راهنمای-مشارکت) و به روز نگه داشتن موضوعات میسر است.
 
-* **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس <span dir="rtl">GitHub</span> ، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد.
+* **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس <span dir="rtl">GitHub</span> ، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد.
 
 [نظرسنجی منبع باز( اوپن سورس) 2017 <span dir="rtl">GitHub</span>](http://opensourcesurvey.org/2017/) که مستندات ناقص و گیچ کننده ای را نشان می داد، بزرگترین مشکل برای کاربران منبع باز می باشد. مستندات خوب، افراد را دعوت می کند که با پروژه‌تان تعامل کنند. در نهایت افراد یک موضوع یا یک درخواست <span dir="rtl">pull</span>( ادغام یا یکپارچگی) را باز خواهند کرد. از این تعاملات به عنوان فرصتهایی برای سوق دادن آنها به پایین قیف استفاده کنید.
 
@@ -168,7 +168,7 @@ related:
 
 * **به همه مشارکت کنندگان دسترسی <span dir="rtl">Commit</span> کردن بدهید.** <span dir="rtl">@fleixge</span> پی برد که این کار، [افراد را وادار می کند](https://felixge.de/2013/03/11/the-pull-request-hack.html) تا با هیجان بیشتری <span dir="rtl">patch</span> هایشان را اصلاح کنند و حتی باعث می شود اعضای جدید برای پروژه هایی بیابید که روی آنها سرمایه گذاری نکرده بودید.
 
-* اگر پروژه تان روی گیت هاب است، **آن را از حساب شخصی خود به یک [سازمان](https://help.github.com/articles/creating-a-new-organization-account/) انتقال دهید** و حداقل یک ادمین پشتیبان به آن بیافزایید. سازمان ها کار کردن روی پروژه هایی با همکاران خارجی را آسانتر می سازند.
+* اگر پروژه تان روی گیت هاب است، **آن را از حساب شخصی خود به یک [سازمان](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) انتقال دهید** و حداقل یک ادمین پشتیبان به آن بیافزایید. سازمان ها کار کردن روی پروژه هایی با همکاران خارجی را آسانتر می سازند.
 
 واقعیت این است که [اکثر پروژه ها](https://peerj.com/preprints/1233/) تنها دارای یک یا دو عضو هستند کسانی که اکثر کار را انجام می دهند. هرچه پروژه تان بزرگتر باشد، و هرچه انجمن تان بزرگتر باشد، دستیابی به کمک ساده تر خواهد بود.
 
diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 1127588f823..4ce2a4435ae 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -440,7 +440,7 @@ related:
 
 قبل از باز کردن <span dir="rtl">issue</span> یا درخواست ادغام، اسناد مشارکت پروژه را بررسی کنید که معمولاً در فایل‌هایی به نام  <span dir="rtl">CONTRIBUTING</span> یا <span dir="rtl">README</span> آورده شدند تا چیزهای خاصی که دنبالش هستید را مطالعه کنید. به عنوان مثال، آن‌ها ممکن است از شما درخواست کنند الگوها را پیروی کنید یا به این نیاز داشته باشند که از این تست‌ها استفاده کنند.
 
-اگر در یک پروژه مشارکت عمیق و اساسی داشته باشید، قبل از مشارکت در پروژه، یک <span dir="rtl">issue</span> باز کنید و سوال کنید. این کار مفید است و باعث می‌شود پروژه‌ی شما مدتی مشاهده شود. (در سایت <span dir="rtl">GitHub</span> می‌توانید [روی «Watch» کلیک کنید](https://help.github.com/articles/watching-repositories/) تا از تمام مکالمات مطلع شوید)، و قبل از انجام دادم کار که ممکن است پذیرفته نشود، اعضای انجمن را بشناسید.
+اگر در یک پروژه مشارکت عمیق و اساسی داشته باشید، قبل از مشارکت در پروژه، یک <span dir="rtl">issue</span> باز کنید و سوال کنید. این کار مفید است و باعث می‌شود پروژه‌ی شما مدتی مشاهده شود. (در سایت <span dir="rtl">GitHub</span> می‌توانید [روی «Watch» کلیک کنید](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) تا از تمام مکالمات مطلع شوید)، و قبل از انجام دادم کار که ممکن است پذیرفته نشود، اعضای انجمن را بشناسید.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -475,7 +475,7 @@ related:
 
 اگر پروژه در <span dir="rtl">GitHub</span> باشد، با روش‌های زیر می‌توانید درخواست ادغام ارسال کنید:
 
-* **[Fork the repository](https://guides.github.com/activities/forking/)** و یک نسخه برای خودتان کپی کنید. نسخه محلی خود را به مخزن بالادستی متصل کنید. هر از چندگاهی با دستور <span dir="rtl">Pull</span> آخرین نسخه تغییرات در مخزن اصلی را دریافت کنید تا پیش از اینکه تعارضی ما بین نسخه محلی و مخزن ایجاد شد بتوانید با مشکلات احتمالی کمتری تغییرات خود را به سمت مخزن اصلی ارسال کنید. [برای کسب اطلاعات بیشتر اینجا را مرور کنید](https://help.github.com/articles/syncing-a-fork/)
+* **[Fork the repository](https://guides.github.com/activities/forking/)** و یک نسخه برای خودتان کپی کنید. نسخه محلی خود را به مخزن بالادستی متصل کنید. هر از چندگاهی با دستور <span dir="rtl">Pull</span> آخرین نسخه تغییرات در مخزن اصلی را دریافت کنید تا پیش از اینکه تعارضی ما بین نسخه محلی و مخزن ایجاد شد بتوانید با مشکلات احتمالی کمتری تغییرات خود را به سمت مخزن اصلی ارسال کنید. [برای کسب اطلاعات بیشتر اینجا را مرور کنید](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork)
 * **[ایجاد یک شاخه](https://guides.github.com/introduction/flow/)** برای اعمال ویرایش ها.
 * در حین ارسال ها **به مسائل <span dir="rtl">(issue)</span> مرتبط ارجاع دهید** یا در کامنت مربوط به تغییرات جدید به مستندات مربوطه اشاره کنید.(مثال: این تغییر مشکل مطرح شده در مسئله شماره 37 را برطرف می‌کند.)
 * اگر تغییرات شما حاوی تفاوت‌های <span dir="rtl">HTML/CSS</span> باشد، **تصاویر مربوط به قبل و بعد آن را اضافه کنید**. تصاویر را وارد بدنه‌ی درخواست ادغام کنید و رها کنید.
diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
index eb7330c28a9..6be0aeb79f9 100644
--- a/_articles/fa/leadership-and-governance.md
+++ b/_articles/fa/leadership-and-governance.md
@@ -73,7 +73,7 @@ related:
 
 ابزارهایی مانند [Vossibility](https://github.com/icecrime/vossibility-stack)، می‌تواند به شما کمک کند تا به طور عمومی افرادی که در پروژه مشارکت می‌کنند (یا نمی‌کنند) را ردیابی کنید. ثبت این اطلاعات، جلوی این ذهنیت اجتماع که نگهدارندگان گروهی هستند که تصمیمات خود را به صورت خصوصی اتخاذ می‌کنند، می‌گیرد
 
-در آخر اینکه اگر پروژه‌ی شما در <span dir="rtl">«GitHub»</span> است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://help.github.com/articles/creating-a-new-organization-account/)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#مالکیت-پروژه-تان-را-به-اشتراک-بگذارید) محافظت می‌کنند.
+در آخر اینکه اگر پروژه‌ی شما در <span dir="rtl">«GitHub»</span> است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#مالکیت-پروژه-تان-را-به-اشتراک-بگذارید) محافظت می‌کنند.
 
 ## چه موقع باید به کسی اجازه‌ی دسترسی کامیت بدهیم؟
 
@@ -81,7 +81,7 @@ related:
 
 از طرف دیگر، به خصوص برای پروژه‌های بزرگتر و پیچیده‌تر، ممکن است بخواهید فقط به افرادی که تعهد خود را نشان داده و به اثبات رسانده‌اند، دسترسی کامیت بدهید. هیچ راه درستی برای انجام این کار وجود ندارد - هر جور که راحت‌تر هستید، عمل کنید!
 
-اگر پروژه‌ی شما در <span dir="rtl">«GitHub»</span> است، می توانید از شاخه‌های محافظت شده [protected branches](https://help.github.com/articles/about-protected-branches/) برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید
+اگر پروژه‌ی شما در <span dir="rtl">«GitHub»</span> است، می توانید از شاخه‌های محافظت شده [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index 3536bfc5eb7..7a5d4a9cfa3 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -26,7 +26,7 @@ related:
 
 ## آیا پروژه‌های عمومی «GitHub» متن باز محسوب می‌شوند؟
 
-هنگام ایجاد [پروژه‌ای جدید](https://help.github.com/articles/creating-a-new-repository/) در «GitHub»، این انتخاب را دارید که منبع را **خصوصی** یا **عمومی** مشخص کنید
+هنگام ایجاد [پروژه‌ای جدید](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) در «GitHub»، این انتخاب را دارید که منبع را **خصوصی** یا **عمومی** مشخص کنید
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -40,7 +40,7 @@ related:
 
 [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/).
+وقتی پروژۀ جدیدی را در «GitHub» ایجاد می‌کنید، [از شما خواسته می‌شود مجوزی را انتخاب کرده و به پروژه اضافه کنید](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ related:
 
 ## آیا پروژۀ من به توافق‌نامه‌های همکاری (مشارکتی) اضافی نیاز دارد؟
 
-به احتمال زیاد نه. برای اکثریت قریب به اتفاق پروژه‌های متن باز، یک مجوز متن آزاد به طور ضمنی به عنوان مجوز درونی (برای مشارکت‌کنندگان) و مجوز خارجی (برای سایر مشارکت‌کنندگان و کاربران) عمل می‌کند. اگر پروژۀ شما در «GitHub» میزبانی می‌شود، شرایط خدمات‌دهی «GitHub»، «مجوزهای درونی و مجوزهای خروجی را [صریحا پیش‌فرض](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license) درنظر می‌گیرد.
+به احتمال زیاد نه. برای اکثریت قریب به اتفاق پروژه‌های متن باز، یک مجوز متن آزاد به طور ضمنی به عنوان مجوز درونی (برای مشارکت‌کنندگان) و مجوز خارجی (برای سایر مشارکت‌کنندگان و کاربران) عمل می‌کند. اگر پروژۀ شما در «GitHub» میزبانی می‌شود، شرایط خدمات‌دهی «GitHub»، «مجوزهای درونی و مجوزهای خروجی را [صریحا پیش‌فرض](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license) درنظر می‌گیرد.
 
 توافق‌نامه‌های همکاری اضافی - که اغلب به آن توافق‌نامه مجوز مشارکت‌کننده (CLA) گفته می‌شود - برای نگهدارندگان پروژه می‌تواند کارهای مدیریتی ایجاد کند. اینکه توافق‌نامه چه مقدار کار اضافه می‌کند به پروژه و نحوۀ اجرای آن بستگی دارد. یک توافق‌نامه‌ی ساده ممکن است نیاز داشته باشد که مشارکت‌کنندگان با یک کلیک تأیید کنند که از حقوق لازم برای مشارکت در مجوز پروژه متن باز برخوردار هستند. یک توافق‌نامه‌ی پیچیده‌تر ممکن است نیاز به بررسی قانونی داشته باشد و مربوط به کارفرمایان مشارکت‌کنندگان شود.
 
diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md
index ea7c2da1f25..8fe52ba1345 100644
--- a/_articles/fa/metrics.md
+++ b/_articles/fa/metrics.md
@@ -37,7 +37,7 @@ related:
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-اگر پروژۀ شما در «GitHub» قرار دارد، [می‌توانید ببینید](https://help.github.com/articles/about-repository-graphs/#traffic) افرادی که در پروژۀ شما هستند از کجا آمده‌اند؟ در صفحه پروژۀ خود، روی «Insights» و سپس «Traffic» کلیک کنید. در این صفحه، این موارد را می‌توانید ببینید:
+اگر پروژۀ شما در «GitHub» قرار دارد، [می‌توانید ببینید](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) افرادی که در پروژۀ شما هستند از کجا آمده‌اند؟ در صفحه پروژۀ خود، روی «Insights» و سپس «Traffic» کلیک کنید. در این صفحه، این موارد را می‌توانید ببینید:
 
 * **تعداد بازدیدها از صفحه:** به شما می‌گوید پروژه چند بار دیده شده است
 
@@ -47,7 +47,7 @@ related:
 
 * **محتوای محبوب:** به شما می‌گوید، بازدیدکنندگان به کدام بخش پروژۀ شما می‌روند و شمار بازدیدهای صفحه و بازدیدکنندگان منحصر به فرد را نشان می‌دهد.
 
-قسمت [GitHub stars](https://help.github.com/articles/about-stars/) هم می‌تواند به صورت معیاری برای محبوبیت عمل کند.اگرچه «GitHub stars» لزوماً با تعداد دانلودها و استفاده از محتوا ارتباط مستقیمی ندارد، اما این قسمت می‌تواند به شما بگوید که چه تعدادی از آدم‌ها متوجه پروژۀ شما شده‌اند..
+قسمت [GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) هم می‌تواند به صورت معیاری برای محبوبیت عمل کند.اگرچه «GitHub stars» لزوماً با تعداد دانلودها و استفاده از محتوا ارتباط مستقیمی ندارد، اما این قسمت می‌تواند به شما بگوید که چه تعدادی از آدم‌ها متوجه پروژۀ شما شده‌اند..
 
 همچنین شاید بخواهید قابلیت کشف شدن (شناخته‌ شدن) را در [بخش‌های مشخصی ردیابی کنید](https://opensource.com/business/16/6/pirate-metrics): به عنوان مثال، «Google PageRank»، ترافیک رجوعی به وب‌سایت پروژۀ شما، یا مراجعات از سایر پروژه‌های متن‌باز یا سایر وب‌سایت‌ها.
 
diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index e2f4a891ccc..ff3ce3c4f2c 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -106,9 +106,9 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 مهم نیست در چه مرحله‌ای تصمیم گرفتید پروژه‌تان را متن باز کنید. هر پروژه‌ای باید حاوی اسناد زیر باشد:
 
-* [لایسنس متن باز](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)
-* [راهنمای مشارکت](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [لایسنس متن باز](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [راهنمای مشارکت](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [آیین نامه رفتار](../code-of-conduct/)
 
 این مؤلفه‌ها به شما به عنوان مسئول‌نگهداری پروژه کمک می‌کند تا انتظارات‌تان را بیان، مشارکت‌ها را مدیریت و از حقوق قانونی خود و دیگران محافظت کنید. این موارد شانس شما را برای داشتن یک تجربه‌ی خوب افزایش می‌دهد.
@@ -182,7 +182,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 برای اینکه بدانید چگونه اطلاعات فایل CONTRIBUTING خود را بنویسید، می‌توانید به مقالات @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) یا @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) مراجعه کنید.
 
-[لینک فایل CONTRIBUTING خود را در فایل README قرار دهید](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) تا افرادی که آن را مطالعه می‌کنند این فایل مشارکت را هم ببینند. اگر فایل CONTRIBUTING خود را در repository (انبار) (مخزن) پروژه‌تان قرار داده باشید، زمانی که یک مشارکت‌کننده طرح مشکل یا گزارش یک باگ یا درخواست ادغام کند، GitHub به صورت خودکار او را به لینک فایل CONTRIBUTING هدایت می‌کند
+[لینک فایل CONTRIBUTING خود را در فایل README قرار دهید](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors) تا افرادی که آن را مطالعه می‌کنند این فایل مشارکت را هم ببینند. اگر فایل CONTRIBUTING خود را در repository (انبار) (مخزن) پروژه‌تان قرار داده باشید، زمانی که یک مشارکت‌کننده طرح مشکل یا گزارش یک باگ یا درخواست ادغام کند، GitHub به صورت خودکار او را به لینک فایل CONTRIBUTING هدایت می‌کند
 
 ![راهنماهای مشارکت](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ _نرم‌افزارهای رایگان_ همچنین به پروژه‌های 
 
 ## مرور (چک لیست / لیست بررسی) قبل از انتشار پروژه‌ی متن باز
 
-خب، آماده هستید تا پروژه‌تان را متن باز کنید؟ چک لیست در این مرحله می‌تواند به شما کمک کند. تمام گزینه‌ها و تیک‌ها را بررسی کرده‌اید؟ به محض آماده شدن، روی انتشار [publish](https://help.github.com/articles/making-a-private-repository-public/) کلیک کنید و به خودتان تبریک بگویید.
+خب، آماده هستید تا پروژه‌تان را متن باز کنید؟ چک لیست در این مرحله می‌تواند به شما کمک کند. تمام گزینه‌ها و تیک‌ها را بررسی کرده‌اید؟ به محض آماده شدن، روی انتشار [publish](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) کلیک کنید و به خودتان تبریک بگویید.
 
 **مستندات**
 
diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md
index e3252b7f877..23380b8cb81 100644
--- a/_articles/fr/best-practices.md
+++ b/_articles/fr/best-practices.md
@@ -213,7 +213,7 @@ L'un des moyens les plus importants pour automatiser votre projet consiste à aj
 
 Les tests aident les contributeurs à croire qu'ils ne casseront rien. Ils facilitent également la consultation et l'acceptation des contributions rapidement. Plus vous êtes réactif, plus votre communauté peut être engagée.
 
-Configurez des tests automatiques qui s'exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. La [vérification du status requis](https://help.github.com/articles/about-required-status-checks/) sur GitHub peut vous aider à vous assurer qu'aucune modification ne sera mergée sans que vos tests ne passent.
+Configurez des tests automatiques qui s'exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. La [vérification du status requis](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) sur GitHub peut vous aider à vous assurer qu'aucune modification ne sera mergée sans que vos tests ne passent.
 
 Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dans votre fichier CONTRIBUTING.
 
diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md
index 1dec5be76ab..dd066f959d3 100644
--- a/_articles/fr/building-community.md
+++ b/_articles/fr/building-community.md
@@ -166,7 +166,7 @@ Voyez si vous pouvez trouver le moyen de partager la propriété avec votre comm
 
 * **Donnez à chaque contributeur un droit de commit.** @felixge a trouvé que cela rendait les gens [plus excités de fignoler leurs patches](https://felixge.de/2013/03/11/the-pull-request-hack.html ), et il a même trouvé de nouveaux responsables pour des projets sur lesquels il n'avait pas travaillé depuis longtemps.
 
-* Si votre projet est sur GitHub, **déplacez votre projet de votre compte personnel vers un [compte Organisation](https://help.github.com/articles/creating-a-new-organization-account/)** et ajoutez au moins un administrateur de sauvegarde. Les organisations facilitent le travail sur des projets avec des collaborateurs externes.
+* Si votre projet est sur GitHub, **déplacez votre projet de votre compte personnel vers un [compte Organisation](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** et ajoutez au moins un administrateur de sauvegarde. Les organisations facilitent le travail sur des projets avec des collaborateurs externes.
 
 La réalité est que [la plupart des projets ont seulement](https://peerj.com/preprints/1233/) un ou deux mainteneurs qui font la plupart du travail. Plus votre projet est important et plus votre communauté est grande, plus il est facile de trouver de l'aide.
 
diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index 83df3ac2c88..c58956eb34d 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -433,7 +433,7 @@ Si vous ne trouvez pas votre idée ailleurs, vous êtes prêt à faire un geste.
 
 Avant d'ouvrir une issue ou une pull request, vérifiez les documents de contribution du projet (généralement un fichier appelé CONTRIBUTING, ou dans le fichier README), pour voir si vous devez inclure quelque chose de spécifique. Par exemple, ils peuvent vous demander de suivre un modèle ou d'exiger que vous utilisiez des tests.
 
-Si vous voulez apporter une contribution substantielle, ouvrez une issue pour demander avant de travailler dessus. Il est utile de regarder le projet pendant un moment (sur GitHub, [vous pouvez cliquer sur "Watch"](https://help.github.com/articles/watching-repositories/) pour être averti de toutes les conversations), et arriver à connaître les membres de la communauté, avant de faire un travail qui pourrait ne pas être accepté.
+Si vous voulez apporter une contribution substantielle, ouvrez une issue pour demander avant de travailler dessus. Il est utile de regarder le projet pendant un moment (sur GitHub, [vous pouvez cliquer sur "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) pour être averti de toutes les conversations), et arriver à connaître les membres de la communauté, avant de faire un travail qui pourrait ne pas être accepté.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -468,7 +468,7 @@ Une pull request n'a pas à représenter le travail fini. Il est généralement
 
 Si le projet est sur GitHub, voici comment soumettre une pull request:
 
-* **[Forker le repository](https://guides.github.com/activities/forking/)** et clonez-le localement. Connectez votre repository local au repository original "upstream" en l'ajoutant en tant que remote. Pullez souvent des changements de "upstream" de sorte que vous restiez à jour afin que lorsque vous soumettez votre pull request, les conflits de merge seront moins probables. (Voir plus d'instructions détaillées [ici](https://help.github.com/articles/syncing-a-fork/).)
+* **[Forker le repository](https://guides.github.com/activities/forking/)** et clonez-le localement. Connectez votre repository local au repository original "upstream" en l'ajoutant en tant que remote. Pullez souvent des changements de "upstream" de sorte que vous restiez à jour afin que lorsque vous soumettez votre pull request, les conflits de merge seront moins probables. (Voir plus d'instructions détaillées [ici](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Créer une branche](https://guides.github.com/introduction/flow/)** pour vos modifications.
 * **Faites référence à toutes les questions pertinentes** ou aux éléments de documentations dans votre PR (par exemple, «Close #37»).
 * **Inclure des captures d'écran avant et après** si vos modifications incluent des différences en HTML/CSS. Faites glisser et déposez les images dans le corps de votre pull request.
diff --git a/_articles/fr/leadership-and-governance.md b/_articles/fr/leadership-and-governance.md
index ca7873e3fbb..45aadf8cffd 100644
--- a/_articles/fr/leadership-and-governance.md
+++ b/_articles/fr/leadership-and-governance.md
@@ -73,7 +73,7 @@ Une fois que vous avez établi des rôles de leadership, n'oubliez pas de docume
 
 Des outils tels que [Vossibility](https://github.com/icecrime/vossibility-stack) peuvent vous aider à savoir qui contribue (ou non) au projet. Documenter cette information évite la perception de la communauté que les responsables sont une clique qui prend ses décisions en privé.
 
-Enfin, si votre projet est sur GitHub, envisagez de transférer votre projet de votre compte personnel vers une organisation et d'ajouter au moins un administrateur de sauvegarde. [Les organisations GitHub](https://help.github.com/articles/creating-a-new-organization-account/) facilitent la gestion des permissions et des dépôts multiples et protègent l'héritage de votre projet par [propriété partagée](../building-community/#partager-la-propri&eacute;t&eacute;-de-votre-projet).
+Enfin, si votre projet est sur GitHub, envisagez de transférer votre projet de votre compte personnel vers une organisation et d'ajouter au moins un administrateur de sauvegarde. [Les organisations GitHub](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) facilitent la gestion des permissions et des dépôts multiples et protègent l'héritage de votre projet par [propriété partagée](../building-community/#partager-la-propri&eacute;t&eacute;-de-votre-projet).
 
 ## Quand dois-je donner &agrave; quelqu'un le droit de commit
 
@@ -81,7 +81,7 @@ Certaines personnes pensent que vous devriez donner un droit de commit à tous c
 
 D'un autre côté, en particulier pour les projets plus volumineux et plus complexes, vous pouvez ne donner que le droit de commit aux personnes qui ont démontré leur engagement. Il n'y a pas une bonne façon de le faire - faites ce qui vous est le plus confortable !
 
-Si votre projet est sur GitHub, vous pouvez utiliser des [branches protégées](https://help.github.com/articles/about-protected-branches/) pour gérer qui peut pousser vers une branche particulière, et dans quelles circonstances.
+Si votre projet est sur GitHub, vous pouvez utiliser des [branches protégées](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) pour gérer qui peut pousser vers une branche particulière, et dans quelles circonstances.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index e8288c1bfcc..adcc9a3271e 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -28,7 +28,7 @@ Enfin, votre projet peut avoir des dépendances avec des exigences de licence do
 
 ## Les projets publics GitHub sont-ils open source
 
-Lorsque vous [créez un nouveau projet](https://help.github.com/articles/creating-a-new-repository/) sur GitHub, vous avez la possibilité de créer le repository **privé** ou **public**.
+Lorsque vous [créez un nouveau projet](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) sur GitHub, vous avez la possibilité de créer le repository **privé** ou **public**.
 
 ![Créer un référentiel](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Vous avez de la chance, car aujourd'hui, les licences open source sont standardi
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), et [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sont les licences open source les plus populaires, mais il existe d'autres options à choisir. Vous pouvez trouver le texte intégral de ces licences, et des instructions sur la façon de les utiliser, sur [choosealicense.com](https://choosealicense.com/).
 
-Lorsque vous créez un nouveau projet sur GitHub, vous serez [invité à ajouter une licence](https://help.github.com/articles/open-source-licensing/).
+Lorsque vous créez un nouveau projet sur GitHub, vous serez [invité à ajouter une licence](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ Alternativement, vous pouvez demander aux contributeurs d'accepter à l'avance (
 
 ## Mon projet a-t-il besoin d'un accord de contribution suppl&eacute;mentaire
 
-Probablement pas. Pour la grande majorité des projets open source, une licence open source sert implicitement à la fois de licence entrante (des contributeurs) et sortante (aux autres contributeurs et utilisateurs). Si votre projet est sur GitHub, les conditions d'utilisation de GitHub font de "inbound = outbound" le [paramètre par défaut explicite](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Probablement pas. Pour la grande majorité des projets open source, une licence open source sert implicitement à la fois de licence entrante (des contributeurs) et sortante (aux autres contributeurs et utilisateurs). Si votre projet est sur GitHub, les conditions d'utilisation de GitHub font de "inbound = outbound" le [paramètre par défaut explicite](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Un accord de contribution supplémentaire - souvent appelé Accord de licence de contributeur (CLA) - peut créer un travail administratif pour les responsables de projet. La quantité de travail ajoutée par un accord dépend du projet et de la mise en œuvre. Un accord simple peut exiger que les contributeurs confirment, en un clic, qu'ils ont les droits nécessaires pour contribuer sous la licence open source du projet. Un accord plus compliqué pourrait nécessiter un examen juridique et une approbation des employeurs des cotisants.
 
diff --git a/_articles/fr/metrics.md b/_articles/fr/metrics.md
index 0d3c83adc01..2a843dbc1be 100644
--- a/_articles/fr/metrics.md
+++ b/_articles/fr/metrics.md
@@ -37,7 +37,7 @@ Avant que quiconque puisse utiliser ou contribuer à votre projet, ils doivent s
 
 ![Graphique de trafic](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Si votre projet est hébergé sur GitHub, [vous pouvez voir](https://help.github.com/articles/about-repository-graphs/#traffic) combien de personnes atterrissent sur votre projet et d'où elles viennent. À partir de la page de votre projet, cliquez sur "Insights", puis sur "Traffic". Sur cette page, vous pouvez voir:
+Si votre projet est hébergé sur GitHub, [vous pouvez voir](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) combien de personnes atterrissent sur votre projet et d'où elles viennent. À partir de la page de votre projet, cliquez sur "Insights", puis sur "Traffic". Sur cette page, vous pouvez voir:
 
 * **Le nombre total de pages vues :** Vous indique combien de fois votre projet a été visionné
 
@@ -47,7 +47,7 @@ Si votre projet est hébergé sur GitHub, [vous pouvez voir](https://help.github
 
 * **Le contenu populaire :** Vous indique où les visiteurs vont sur votre projet, ventilé par pages vues et visiteurs uniques.
 
-[Les étoiles de GitHub](https://help.github.com/articles/about-stars/) peuvent également aider à fournir une mesure de base de popularité. Bien que les étoiles GitHub ne correspondent pas nécessairement aux téléchargements et à l'utilisation, elles peuvent vous dire combien de personnes prennent en compte votre travail.
+[Les étoiles de GitHub](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) peuvent également aider à fournir une mesure de base de popularité. Bien que les étoiles GitHub ne correspondent pas nécessairement aux téléchargements et à l'utilisation, elles peuvent vous dire combien de personnes prennent en compte votre travail.
 
 Vous pouvez également [suivre la découvrabilité dans des lieux spécifiques](https://opensource.com/business/16/6/pirate-metrics): par exemple, Google PageRank, le trafic de redirection depuis le site Web de votre projet ou les renvois d'autres sites ouverts, projets source ou sites Web.
 
diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index e046bda6d19..c7737a7cb0f 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -113,9 +113,9 @@ De manière générale, vous devriez ouvrir votre projet lorsque vous serez à l
 
 Quelle que soit la phase durant laquelle vous décidez d'ouvrir votre projet, chaque projet doit inclure la documentation suivante :
 
-* [Licence open source](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)
-* [Directives de contribution](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Licence open source](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Directives de contribution](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code de conduite](../code-of-conduct/)
 
 En tant que responsable, ces composants vous aideront à communiquer les attentes, à gérer les contributions et à protéger les droits légaux de chacun (y compris les vôtres). Ils augmentent considérablement vos chances d'avoir une expérience positive.
@@ -189,7 +189,7 @@ Au fil du temps, vous pouvez ajouter d'autres questions fréquemment posées à
 
 Pour plus d'aide avec la rédaction de votre fichier CONTRIBUTING, consultez le [modèle de guide de contribution de @nayafia](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) ou le guide de @mozilla ["Comment Construire un CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Ajoutez un lien vers votre fichier CONTRIBUTING dans votre fichier README, afin que plus de gens le voient. Si vous [placez le fichier CONTRIBUTING dans le repository de votre projet](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub affichera automatiquement un lien vers votre fichier lorsqu'un contributeur crée un problème ou ouvre une pull request.
+Ajoutez un lien vers votre fichier CONTRIBUTING dans votre fichier README, afin que plus de gens le voient. Si vous [placez le fichier CONTRIBUTING dans le repository de votre projet](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub affichera automatiquement un lien vers votre fichier lorsqu'un contributeur crée un problème ou ouvre une pull request.
 
 ![Lignes directrices contributives](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -262,7 +262,7 @@ Il n'est pas nécessaire d'écrire un guide de style pour votre projet lorsque v
 
 ## Votre checklist de pr&eacute;-lancement
 
-Prêt à lancer votre projet open source ? Voici une checklist pour vous aider. Toutes les cases sont cochées ? Vous êtes prêt à vous lancer ! [Cliquez sur "Publier"] (https://help.github.com/articles/making-a-private-repository-public/) et donnez vous une tape dans le dos.
+Prêt à lancer votre projet open source ? Voici une checklist pour vous aider. Toutes les cases sont cochées ? Vous êtes prêt à vous lancer ! [Cliquez sur "Publier"] (https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) et donnez vous une tape dans le dos.
 
 **Documentation**
 
diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md
index db31c75bfe7..2b9a730710e 100644
--- a/_articles/hi/best-practices.md
+++ b/_articles/hi/best-practices.md
@@ -166,7 +166,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
 
 यदि आप मदद के लिए दूसरों की तलाश कर रहे हैं, तो आसपास पूछकर शुरुआत करें।
 
-नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [ऐसे लेबल मुद्दे जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी।
+नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [ऐसे लेबल मुद्दे जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी।
 
 जब आप नए योगदानकर्ताओं को बार-बार योगदान करते हुए देखें, तो अधिक जिम्मेदारी देकर उनके काम को पहचानें। दस्तावेज़ बनाएं कि यदि अन्य लोग चाहें तो नेतृत्व की भूमिका में कैसे विकसित हो सकते हैं।
 
@@ -216,7 +216,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
 
 परीक्षण योगदानकर्ताओं को यह विश्वास दिलाने में मदद करते हैं कि वे कुछ भी नहीं तोड़ेंगे। वे आपके लिए योगदान की शीघ्रता से समीक्षा करना और स्वीकार करना भी आसान बनाते हैं। आप जितने अधिक संवेदनशील होंगे, आपका समुदाय उतना ही अधिक सक्रिय हो सकता है।
 
-स्वचालित परीक्षण सेट करें जो आने वाले सभी योगदानों पर चलेंगे, और सुनिश्चित करें कि आपके परीक्षण योगदानकर्ताओं द्वारा स्थानीय स्तर पर आसानी से चलाए जा सकें। आवश्यक है कि सबमिट किए जाने से पहले सभी कोड योगदान आपके परीक्षणों में उत्तीर्ण हों। आप सभी प्रस्तुतियों के लिए गुणवत्ता का न्यूनतम मानक निर्धारित करने में मदद करेंगे। GitHub पर [आवश्यक स्थिति जांच](https://help.github.com/articles/about-required-status-checks/) यह सुनिश्चित करने में मदद कर सकता है कि आपके परीक्षण पास किए बिना कोई भी परिवर्तन मर्ज नहीं किया जाएगा।
+स्वचालित परीक्षण सेट करें जो आने वाले सभी योगदानों पर चलेंगे, और सुनिश्चित करें कि आपके परीक्षण योगदानकर्ताओं द्वारा स्थानीय स्तर पर आसानी से चलाए जा सकें। आवश्यक है कि सबमिट किए जाने से पहले सभी कोड योगदान आपके परीक्षणों में उत्तीर्ण हों। आप सभी प्रस्तुतियों के लिए गुणवत्ता का न्यूनतम मानक निर्धारित करने में मदद करेंगे। GitHub पर [आवश्यक स्थिति जांच](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) यह सुनिश्चित करने में मदद कर सकता है कि आपके परीक्षण पास किए बिना कोई भी परिवर्तन मर्ज नहीं किया जाएगा।
 
 यदि आप परीक्षण जोड़ते हैं, तो यह बताना सुनिश्चित करें कि वे आपकी CONTRIBUTING फ़ाइल में कैसे काम करते हैं।
 
diff --git a/_articles/hi/building-community.md b/_articles/hi/building-community.md
index 642194d3c0b..9132a65eaf0 100644
--- a/_articles/hi/building-community.md
+++ b/_articles/hi/building-community.md
@@ -29,7 +29,7 @@ related:
 * **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [एक मैत्रीपूर्ण README लिखना](../starting-a-project/#एक-रीडमी-लिखना) 
 और स्पष्ट कोड उदाहरण आपके प्रोजेक्ट पर आने वाले किसी भी व्यक्ति के लिए आरंभ करना आसान बना देंगे।  
 * **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल का उपयोग करके](../starting-a-project/#अपने-योगदान-संबंधी-दिशानिर्देश-लिखना) और अपने मुद्दों को अद्यतन रखते हुए।
-* **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं।
+* **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं।
 
 [GitHub का 2017 ओपन सोर्स सर्वेक्षण](http://opensourcesurvey.org/2017/) अपूर्ण या भ्रमित करने वाला दस्तावेज़ दिखाना ओपन सोर्स उपयोगकर्ताओं के लिए सबसे बड़ी समस्या है। अच्छा दस्तावेज़ीकरण लोगों को आपके प्रोजेक्ट के साथ बातचीत करने के लिए आमंत्रित करता है। अंततः, कोई व्यक्ति कोई समस्या खोलेगा या अनुरोध खींच लेगा। इन इंटरैक्शन को फ़नल से नीचे ले जाने के अवसर के रूप में उपयोग करें।
 
@@ -168,7 +168,7 @@ related:
 
 * **प्रत्येक योगदानकर्ता को पहुंच प्रदान करें** @felixge ने पाया कि इसने लोगों को बनाया है [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), और उन्हें उन परियोजनाओं के लिए नए अनुरक्षक भी मिल गए जिन पर उन्होंने कुछ समय से काम नहीं किया था।
 
-* यदि आपका प्रोजेक्ट GitHub पर है, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** और कम से कम एक बैकअप व्यवस्थापक जोड़ें. संगठन बाहरी सहयोगियों के साथ परियोजनाओं पर काम करना आसान बनाते हैं।
+* यदि आपका प्रोजेक्ट GitHub पर है, **move your project from your personal account to an [Organization](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** और कम से कम एक बैकअप व्यवस्थापक जोड़ें. संगठन बाहरी सहयोगियों के साथ परियोजनाओं पर काम करना आसान बनाते हैं।
 
 हकीकत तो यही है [most projects only have](https://peerj.com/preprints/1233/) एक या दो अनुरक्षक जो अधिकांश कार्य करते हैं। आपका प्रोजेक्ट जितना बड़ा होगा, और आपका समुदाय जितना बड़ा होगा, सहायता पाना उतना ही आसान होगा।
 
diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
index ad6e4fdbbc6..c78db07be9f 100644
--- a/_articles/hi/how-to-contribute.md
+++ b/_articles/hi/how-to-contribute.md
@@ -440,7 +440,7 @@ Main branch पर commit प्रतिबद्ध को देखें।
 
 किसी मुद्दे को खोलने या अनुरोध खींचने से पहले, यह देखने के लिए कि क्या आपको कुछ विशिष्ट शामिल करने की आवश्यकता है, प्रोजेक्ट के योगदान दस्तावेज़ (आमतौर पर CONTRIBUTING या README में एक फ़ाइल) की जाँच करें। उदाहरण के लिए, वे आपसे एक टेम्पलेट का पालन करने के लिए कह सकते हैं, या आपसे परीक्षण का उपयोग करने के लिए कह सकते हैं।
 
-यदि आप कोई महत्वपूर्ण योगदान देना चाहते हैं, तो उस पर काम करने से पहले पूछने के लिए एक मुद्दा खोलें। प्रोजेक्ट को कुछ समय के लिए देखना उपयोगी है (GitHub पर, [आप "watch" पर क्लिक कर सकते हैं)](https://help.github.com/articles/watching-repositories/) सभी वार्तालापों की सूचना प्राप्त करने के लिए), और वह काम करने से पहले समुदाय के सदस्यों को जानें जिन्हें स्वीकार नहीं किया जा सकता है।
+यदि आप कोई महत्वपूर्ण योगदान देना चाहते हैं, तो उस पर काम करने से पहले पूछने के लिए एक मुद्दा खोलें। प्रोजेक्ट को कुछ समय के लिए देखना उपयोगी है (GitHub पर, [आप "watch" पर क्लिक कर सकते हैं)](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) सभी वार्तालापों की सूचना प्राप्त करने के लिए), और वह काम करने से पहले समुदाय के सदस्यों को जानें जिन्हें स्वीकार नहीं किया जा सकता है।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -475,7 +475,7 @@ Main branch पर commit प्रतिबद्ध को देखें।
 
 यदि प्रोजेक्ट GitHub पर है, तो पुल अनुरोध सबमिट करने का तरीका यहां दिया गया है:
 
-* **[रेपासटरी को फोर्क करें](https://guides.github.com/activities/forking/)** और इसे स्थानीय रूप से क्लोन करें। अपने लोकल को रिमोट के रूप में जोड़कर मूल "अपस्ट्रीम" रिपॉजिटरी से कनेक्ट करें। "अपस्ट्रीम" से परिवर्तन अक्सर खींचें ताकि आप अद्यतित रहें ताकि जब आप अपना पुल अनुरोध सबमिट करें, तो मर्ज विवादों की संभावना कम हो जाएगी। (अधिक विस्तृत निर्देश देखें [यहाँ](https://help.github.com/articles/syncing-a-fork/).)
+* **[रेपासटरी को फोर्क करें](https://guides.github.com/activities/forking/)** और इसे स्थानीय रूप से क्लोन करें। अपने लोकल को रिमोट के रूप में जोड़कर मूल "अपस्ट्रीम" रिपॉजिटरी से कनेक्ट करें। "अपस्ट्रीम" से परिवर्तन अक्सर खींचें ताकि आप अद्यतित रहें ताकि जब आप अपना पुल अनुरोध सबमिट करें, तो मर्ज विवादों की संभावना कम हो जाएगी। (अधिक विस्तृत निर्देश देखें [यहाँ](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[एक ब्रेनच बनाएँ](https://guides.github.com/introduction/flow/)** आपके संपादनों के लिए.
 * **अपने पीआर में किसी भी प्रासंगिक मुद्दे** या सहायक दस्तावेज़ का संदर्भ लें (उदाहरण के लिए, " #37 बंद होता है।")
 * **यदि आपके परिवर्तनों में HTML/CSS में अंतर शामिल है तो पहले और बाद के स्क्रीनशॉट शामिल करें**। छवियों को अपने पुल अनुरोध के मुख्य भाग में खींचें और छोड़ें।
diff --git a/_articles/hi/leadership-and-governance.md b/_articles/hi/leadership-and-governance.md
index aa191f5f602..70571710c11 100644
--- a/_articles/hi/leadership-and-governance.md
+++ b/_articles/hi/leadership-and-governance.md
@@ -73,7 +73,7 @@ related:
 
 उपकरण जैसे [Vossibility](https://github.com/icecrime/vossibility-stack) आपको सार्वजनिक रूप से ट्रैक करने में मदद मिल सकती है कि प्रोजेक्ट में कौन योगदान दे रहा है (या नहीं दे रहा है)। इस जानकारी का दस्तावेजीकरण करने से समुदाय की इस धारणा से बचा जा सकता है कि रखरखाव करने वाले एक समूह हैं जो निजी तौर पर अपने निर्णय लेते हैं।
 
-अंत में, यदि आपका प्रोजेक्ट GitHub पर है, तो अपने प्रोजेक्ट को अपने व्यक्तिगत खाते से किसी संगठन में ले जाने और कम से कम एक बैकअप व्यवस्थापक जोड़ने पर विचार करें। [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) अनुमतियों और एकाधिक रिपॉजिटरी को प्रबंधित करना और अपने प्रोजेक्ट की विरासत को सुरक्षित रखना आसान बनाएं [shared ownership](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें).
+अंत में, यदि आपका प्रोजेक्ट GitHub पर है, तो अपने प्रोजेक्ट को अपने व्यक्तिगत खाते से किसी संगठन में ले जाने और कम से कम एक बैकअप व्यवस्थापक जोड़ने पर विचार करें। [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) अनुमतियों और एकाधिक रिपॉजिटरी को प्रबंधित करना और अपने प्रोजेक्ट की विरासत को सुरक्षित रखना आसान बनाएं [shared ownership](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें).
 
 ## मुझे किसी को प्रतिबद्ध पहुंच कब देनी चाहिए?
 
@@ -81,7 +81,7 @@ related:
 
 दूसरी ओर, विशेष रूप से बड़ी, अधिक जटिल परियोजनाओं के लिए, आप केवल उन लोगों को प्रतिबद्ध पहुंच देना चाह सकते हैं जिन्होंने अपनी प्रतिबद्धता प्रदर्शित की है। इसे करने का कोई एक सही तरीका नहीं है - वही करें जो आपको सबसे अधिक आरामदायक लगे!
 
-यदि आपका प्रोजेक्ट GitHub पर है, तो आप इसका उपयोग कर सकते हैं [protected branches](https://help.github.com/articles/about-protected-branches/) यह प्रबंधित करना कि कौन किसी विशेष शाखा में जा सकता है, और किन परिस्थितियों में।
+यदि आपका प्रोजेक्ट GitHub पर है, तो आप इसका उपयोग कर सकते हैं [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) यह प्रबंधित करना कि कौन किसी विशेष शाखा में जा सकता है, और किन परिस्थितियों में।
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index 7ad3b9bdf9a..d156feb74e3 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -28,7 +28,7 @@ related:
 
 ## क्या सार्वजनिक GitHub परियोजनाएँ खुला स्रोत हैं?
 
-जब आप GitHub पर [एक नया प्रोजेक्ट बनाते हैं](https://help.github.com/articles/creating-a-new-repository/), तो आपके पास रिपॉजिटरी को **private** या **public** बनाने का विकल्प होता है।
+जब आप GitHub पर [एक नया प्रोजेक्ट बनाते हैं](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository), तो आपके पास रिपॉजिटरी को **private** या **public** बनाने का विकल्प होता है।
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -43,7 +43,7 @@ related:
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) 
 सबसे लोकप्रिय ओपन सोर्स लाइसेंस हैं, लेकिन चुनने के लिए अन्य विकल्प भी हैं। आप इन लाइसेंसों का पूरा पाठ और उनका उपयोग करने के तरीके के बारे में निर्देश यहां पा सकते हैं[choosealicense.com](https://choosealicense.com/).
 
-जब आप GitHub पर एक नया प्रोजेक्ट बनाएंगे, तो आप होंगे [लाइसेंस जोड़ने के लिए कहा गया](https://help.github.com/articles/open-source-licensing/).
+जब आप GitHub पर एक नया प्रोजेक्ट बनाएंगे, तो आप होंगे [लाइसेंस जोड़ने के लिए कहा गया](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -91,7 +91,7 @@ related:
 
 ## क्या मेरे प्रोजेक्ट को अतिरिक्त योगदानकर्ता समझौते की आवश्यकता है?
 
-शायद नहीं। अधिकांश ओपन सोर्स परियोजनाओं के लिए, एक ओपन सोर्स लाइसेंस अंतर्निहित रूप से इनबाउंड (योगदानकर्ताओं से) और आउटबाउंड (अन्य योगदानकर्ताओं और उपयोगकर्ताओं के लिए) लाइसेंस दोनों के रूप में कार्य करता है।यदि आपका प्रोजेक्ट GitHub पर है, तो GitHub सेवा की शर्तें "इनबाउंड = आउटबाउंड" बनाती हैं [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+शायद नहीं। अधिकांश ओपन सोर्स परियोजनाओं के लिए, एक ओपन सोर्स लाइसेंस अंतर्निहित रूप से इनबाउंड (योगदानकर्ताओं से) और आउटबाउंड (अन्य योगदानकर्ताओं और उपयोगकर्ताओं के लिए) लाइसेंस दोनों के रूप में कार्य करता है।यदि आपका प्रोजेक्ट GitHub पर है, तो GitHub सेवा की शर्तें "इनबाउंड = आउटबाउंड" बनाती हैं [explicit default](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 एक अतिरिक्त योगदानकर्ता समझौता - जिसे अक्सर Contributor License Agreement (CLA) कहा जाता है - परियोजना अनुरक्षकों के लिए प्रशासनिक कार्य बना सकता है। एक समझौता कितना काम जोड़ता है यह परियोजना और कार्यान्वयन पर निर्भर करता है। एक साधारण समझौते के लिए आवश्यक हो सकता है कि योगदानकर्ता एक क्लिक के साथ पुष्टि करें कि उनके पास प्रोजेक्ट ओपन सोर्स लाइसेंस के तहत योगदान करने के लिए आवश्यक अधिकार हैं। अधिक जटिल समझौते के लिए कानूनी समीक्षा और योगदानकर्ताओं के नियोक्ताओं से हस्ताक्षर की आवश्यकता हो सकती है।
 
diff --git a/_articles/hi/metrics.md b/_articles/hi/metrics.md
index 5f4de85f9ba..c3618df6068 100644
--- a/_articles/hi/metrics.md
+++ b/_articles/hi/metrics.md
@@ -37,7 +37,7 @@ related:
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, [आप देख सकते हैं](https://help.github.com/articles/about-repository-graphs/#traffic) आपके प्रोजेक्ट पर कितने लोग आते हैं और वे कहाँ से आते हैं। अपने प्रोजेक्ट के पेज से, "इनसाइट्स" पर क्लिक करें, फिर "ट्रैफ़िक" पर क्लिक करें। इस पृष्ठ पर, आप देख सकते हैं:
+यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, [आप देख सकते हैं](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) आपके प्रोजेक्ट पर कितने लोग आते हैं और वे कहाँ से आते हैं। अपने प्रोजेक्ट के पेज से, "इनसाइट्स" पर क्लिक करें, फिर "ट्रैफ़िक" पर क्लिक करें। इस पृष्ठ पर, आप देख सकते हैं:
 
 * **कुल पृष्ठ दृश्य:** आपको बताता है कि आपका प्रोजेक्ट कितनी बार देखा गया
 
@@ -47,7 +47,7 @@ related:
 
 * **लोकप्रिय सामग्री:** आपको बताती है कि विज़िटर आपके प्रोजेक्ट पर कहां जाते हैं, पृष्ठ दृश्य और अद्वितीय विज़िटर के आधार पर।
 
-[गिटहब सितारे](https://help.github.com/articles/about-stars/) लोकप्रियता का आधारभूत माप प्रदान करने में भी मदद मिल सकती है। हालाँकि GitHub सितारे आवश्यक रूप से डाउनलोड और उपयोग से संबंधित नहीं हैं, वे आपको बता सकते हैं कि कितने लोग आपके काम पर ध्यान दे रहे हैं।
+[गिटहब सितारे](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) लोकप्रियता का आधारभूत माप प्रदान करने में भी मदद मिल सकती है। हालाँकि GitHub सितारे आवश्यक रूप से डाउनलोड और उपयोग से संबंधित नहीं हैं, वे आपको बता सकते हैं कि कितने लोग आपके काम पर ध्यान दे रहे हैं।
 
 आप भी चाहते होंगे [tविशिष्ट स्थानों में रैक खोज योग्यता](https://opensource.com/business/16/6/pirate-metrics): उदाहरण के लिए, Google पेजरैंक, आपके प्रोजेक्ट की वेबसाइट से रेफरल ट्रैफ़िक, या अन्य ओपन सोर्स प्रोजेक्ट या वेबसाइट से रेफरल।
 
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index fc320784b03..51588731d7c 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -106,9 +106,9 @@ _मुफ़्त सॉफ़्टवेयर_ परियोजनाओ
 
 इससे कोई फर्क नहीं पड़ता कि आप अपने प्रोजेक्ट को किस चरण में खोलने का निर्णय लेते हैं, प्रत्येक प्रोजेक्ट में निम्नलिखित दस्तावेज़ शामिल होने चाहिए:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 एक अनुरक्षक के रूप में, ये घटक आपको अपेक्षाओं को संप्रेषित करने, योगदान प्रबंधित करने और सभी के कानूनी अधिकारों (आपके अपने अधिकारों सहित) की रक्षा करने में मदद करेंगे। वे आपके सकारात्मक अनुभव प्राप्त करने की संभावनाओं को उल्लेखनीय रूप से बढ़ा देते हैं।
@@ -182,7 +182,7 @@ READMEs आपके प्रोजेक्ट का उपयोग कै
 
 अपनी CONTRIBUTING फ़ाइल लिखने में अधिक सहायता के लिए, देखें @nayafia's [contributing गाइड टेम्पलेट](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) या @mozilla's ["CONTRIBUTING.md कैसे बनाएं।"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-अपनी CONTRIBUTING फ़ाइल को अपने README से लिंक करें, ताकि अधिक लोग इसे देख सकें। यदि आप [CONTRIBUTING फ़ाइल को अपने प्रोजेक्ट के भंडार में रखते हैं](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), जब कोई योगदानकर्ता कोई समस्या उत्पन्न करता है या पुल अनुरोध खोलता है तो GitHub स्वचालित रूप से आपकी फ़ाइल से लिंक हो जाएगा।
+अपनी CONTRIBUTING फ़ाइल को अपने README से लिंक करें, ताकि अधिक लोग इसे देख सकें। यदि आप [CONTRIBUTING फ़ाइल को अपने प्रोजेक्ट के भंडार में रखते हैं](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), जब कोई योगदानकर्ता कोई समस्या उत्पन्न करता है या पुल अनुरोध खोलता है तो GitHub स्वचालित रूप से आपकी फ़ाइल से लिंक हो जाएगा।
 
 ![योगदान दिशानिर्देश](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ READMEs आपके प्रोजेक्ट का उपयोग कै
 
 ## आपकी प्री-लॉन्च चेकलिस्ट
 
-क्या आप अपना प्रोजेक्ट ओपन सोर्स करने के लिए तैयार हैं? मदद के लिए यहां एक चेकलिस्ट दी गई है। सभी बक्सों की जाँच करें? आप जाने के लिए तैयार हैं! ["प्रकाशित करें" पर क्लिक करें](https://help.github.com/articles/making-a-private-repository-public/) और अपनी पीठ थपथपाएं।
+क्या आप अपना प्रोजेक्ट ओपन सोर्स करने के लिए तैयार हैं? मदद के लिए यहां एक चेकलिस्ट दी गई है। सभी बक्सों की जाँच करें? आप जाने के लिए तैयार हैं! ["प्रकाशित करें" पर क्लिक करें](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) और अपनी पीठ थपथपाएं।
 
 **दस्तावेज़ीकरण**
 
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 97b32ca9e41..9414919657b 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -448,7 +448,7 @@ If you can't find your idea elsewhere, you're ready to make a move. If the proje
 
 Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests.
 
-If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted.
+If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) to be notified of all conversations), and get to know community members, before doing work that might not get accepted.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -483,7 +483,7 @@ A pull request doesn't have to represent finished work. It's usually better to o
 
 If the project is on GitHub, here's how to submit a pull request:
 
-* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
 * **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
 * **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md
index c4c9ecd2d31..091831ba203 100644
--- a/_articles/hu/best-practices.md
+++ b/_articles/hu/best-practices.md
@@ -165,7 +165,7 @@ Nem kell mindent egymagad csinálni. A projekt közösség okkal létezik! Ha m
 
 Ha szeretnél másokat bevonni, akkor kérdezz körbe.
 
-Az új közreműködők megszerzésének egyik módja az, hogy kifejezetten [olyan issue-kat nevezel meg, amelyek elég egyszerűek a kezdők számára](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). A GitHub segíti ezen issue-k kiemelésén és láthatóvá tételét.
+Az új közreműködők megszerzésének egyik módja az, hogy kifejezetten [olyan issue-kat nevezel meg, amelyek elég egyszerűek a kezdők számára](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). A GitHub segíti ezen issue-k kiemelésén és láthatóvá tételét.
 
 Amikor azt látod, hogy az új résztvevők rendszeresen hozzájárulnak a projekthez, akkor ismerd el a munkájukat azzal, hogy nagyobb felelősséget adsz számukra. Dokumentáld le, hogy hogyan válhat valaki a projekt irányító tagjává, ha azt szeretné.
 
@@ -215,7 +215,7 @@ A projekt automatizálásának egyik legfontosabb módja a tesztek hozzáadása.
 
 A tesztek segítenek a közreműködőknek, hogy biztosak legyenek abban, hogy semmit sem rontanak el. Ezenkívül megkönnyítik az észrevételek gyors áttekintését és elfogadását. Minél jobban és gyorsabban reagálsz, annál elkötelezettebbé válhat a közösség.
 
-Állíts be automatikus teszteket, amelyek az összes bejövő hozzájárulásra futnak, és győződj meg arról, hogy a teszteket a közreműködők könnyen, a saját gépeiken is futtathatják. Mielőtt beküldenék a hozzájárulásokat, követeld meg, hogy az összes kódminőségi követelményt teljesítse, minden teszten átmenjen. Itt egy segítség a minimális minőségi követelmények megkövetelésére: [Kötelező ellenőrzések](https://help.github.com/articles/about-required-status-checks/), a GitHub segít abban, hogy ellenőrzés nélkül a hozzájárulás ne kerüljön beolvasztásra.
+Állíts be automatikus teszteket, amelyek az összes bejövő hozzájárulásra futnak, és győződj meg arról, hogy a teszteket a közreműködők könnyen, a saját gépeiken is futtathatják. Mielőtt beküldenék a hozzájárulásokat, követeld meg, hogy az összes kódminőségi követelményt teljesítse, minden teszten átmenjen. Itt egy segítség a minimális minőségi követelmények megkövetelésére: [Kötelező ellenőrzések](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging), a GitHub segít abban, hogy ellenőrzés nélkül a hozzájárulás ne kerüljön beolvasztásra.
 
 Ha teszteket adsz hozzá, akkor bizonyosodj meg arról, hogy elmagyaráztad azt a CONTRIBUTING.md fájlban, hogy hogyan működnek.
 
diff --git a/_articles/hu/building-community.md b/_articles/hu/building-community.md
index e771c1f5641..24b4479f94f 100644
--- a/_articles/hu/building-community.md
+++ b/_articles/hu/building-community.md
@@ -28,7 +28,7 @@ Kezd a dokumentációkkal:
 
 * **Tedd egyszerűvé, hogy valaki könnyen használhassa a projektedet!** [Egy barátságos README](../starting-a-project/#readme-írása) és tiszta kód példák mindenkit hozzásegítenek ahhoz, hogy könnyen el tudjanak indulni.
 * **Tisztán és érthetően magyarázd el, hogy hogyan lehet hozzájárulni**, használd a [CONTRIBUTING fájlodat](../starting-a-project/#részvételi-irányelvek-leírása) és a hibajelzéseket tartsd naprakészen.
-* **Good first issues**: Az új hozzájárulókat segíti az, ha egyértelműen [jelezve van címkével az issue, amely kezdőknek ajánlott](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). A GitHub kiemeli ezeket az issue-kat, és ezzel segíti a hasznos hozzájárulásokat úgy, hogy a hozzájáruló szintjének megfelelő hibát ajánl megoldásra.
+* **Good first issues**: Az új hozzájárulókat segíti az, ha egyértelműen [jelezve van címkével az issue, amely kezdőknek ajánlott](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). A GitHub kiemeli ezeket az issue-kat, és ezzel segíti a hasznos hozzájárulásokat úgy, hogy a hozzájáruló szintjének megfelelő hibát ajánl megoldásra.
 
 [A GitHub 2017. évi nyílt forráskódú felmérése](http://opensourcesurvey.org/2017/) azt mutatta ki, hogy a félkész és zavaros dokumentáció a legnagyobb probléma a felhasználók számára. A jó dokumentáció beszippantja az embereket a projektbe: egyszer csak valaki nyit egy hibajelzést, vagy beküld egy beolvasztási kérelmet. Használd ki ezeket a lehetőségeket, hogy az emberek tovább mozogjanak lefelé a _résztvevői tölcséren_.
 
@@ -167,7 +167,7 @@ Nézd meg, hogyan találhatod meg a módját, hogy a lehető legnagyobb mérték
 
 * **Minden közreműködő kapjon commit jogot.** @felixge szerint az emberek [sokkal aprólékosabban kidolgozzák a hozzájárulásukat](https://felixge.de/2013/03/11/the-pull-request-hack.html), és még több karbantartót lehet bevonni, akik esetleg korábban passzívak voltak.
 
-* Ha a projekted a GitHub-on van, **akkor mozgasd a projektet át a személyes fiókod alól a [Szervezeti Fiók](https://help.github.com/articles/creating-a-new-organization-account/)** alá és adj hozzá legalább egy admint még biztonság esetére. Az Szervezeti Fiók alkalmasabb külső résztvevők bevonására.
+* Ha a projekted a GitHub-on van, **akkor mozgasd a projektet át a személyes fiókod alól a [Szervezeti Fiók](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** alá és adj hozzá legalább egy admint még biztonság esetére. Az Szervezeti Fiók alkalmasabb külső résztvevők bevonására.
 
 A valóságban [a legtöbb projektnek](https://peerj.com/preprints/1233/) csak egy, két karbantartója van. Minél nagyobb a projekted, és a közösséged, annál könnyebb segítséget találni.
 
diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md
index 479d5712f29..0d8d2885e8b 100644
--- a/_articles/hu/how-to-contribute.md
+++ b/_articles/hu/how-to-contribute.md
@@ -435,7 +435,7 @@ Ha nem találod meg a felvetést sehol, akkor mehetsz tovább. Ha a projekt a Gi
 
 Mielőtt hibajegyet, észrevételt vennél fel, vagy egy beolvasztási kérelmet benyújtanál, ellenőrizd a projektben való részvételről szóló dokumentációt (ezt gyakran a CONTRIBUTING vagy a README tartalmazza), mert lehetséges, hogy mellékelned kell valamilyen specifikus információt is. Például, a projekt kérheti azt, hogy egy űrlapot tölts ki, vagy megkövetelheti a teszteket.
 
-Ha jelentősebb munkával akarsz részt venni, akkor nyiss egy probléma felvetést tartalmazó jegyet, ahol a kérdéseket meg lehet vitatni, mielőtt még nekikezdenél. Hasznos, ha egy darabig csak nyomon követed a projektet és a közösséget (a GitHub-on, [klikkents a "Watch" linkre](https://help.github.com/articles/watching-repositories/) hogy értesítést kapj az összes beszélgetésről), hogy megismerd a tagjait, mielőtt olyan munkát végeznél benne, amit nem fogadnak el.
+Ha jelentősebb munkával akarsz részt venni, akkor nyiss egy probléma felvetést tartalmazó jegyet, ahol a kérdéseket meg lehet vitatni, mielőtt még nekikezdenél. Hasznos, ha egy darabig csak nyomon követed a projektet és a közösséget (a GitHub-on, [klikkents a "Watch" linkre](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) hogy értesítést kapj az összes beszélgetésről), hogy megismerd a tagjait, mielőtt olyan munkát végeznél benne, amit nem fogadnak el.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -470,7 +470,7 @@ A beolvasztási kérelem nem feltétlen jelent befejezett munkát. Gyakran jobb
 
 Ha a projekt a GitHub-on van, akkor a következőképpen kell beolvasztási kérelmet benyújtani:
 
-* **[Ágaztasd (fork) el a kód tározót](https://guides.github.com/activities/forking/)** és klónozd le magadhoz lokálisan. A lokális másolatodat kapcsold az eredeti tárolóhoz (original "upstream") egy _remote_ hozzáadásával. Frissítsd minél gyakrabban a változásokat az "upstream"-ről, hogy naprakész maradj. Így beolvasztás esetén kisebb eséllyel lesz ütközés a kódok összefésülésekor. (Részletes instrukciókat [itt találsz](https://help.github.com/articles/syncing-a-fork/).)
+* **[Ágaztasd (fork) el a kód tározót](https://guides.github.com/activities/forking/)** és klónozd le magadhoz lokálisan. A lokális másolatodat kapcsold az eredeti tárolóhoz (original "upstream") egy _remote_ hozzáadásával. Frissítsd minél gyakrabban a változásokat az "upstream"-ről, hogy naprakész maradj. Így beolvasztás esetén kisebb eséllyel lesz ütközés a kódok összefésülésekor. (Részletes instrukciókat [itt találsz](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Hozz létre egy új ágat (branch)](https://guides.github.com/introduction/flow/)** a módosításaidhoz.
 * **Hivatkozz meg bármilyen releváns hibajegyet** vagy a dokumentációt a beolvasztási kérelmedben (például, "Closes #37.")
 * **Adj hozzá a kérelmedhez "előtte" és "utána" képernyőképeket** ha HTML/CSS változás történt. Húzd be a képeket a beolvasztási kérelembe.
diff --git a/_articles/hu/leadership-and-governance.md b/_articles/hu/leadership-and-governance.md
index 94c9d2de66a..7acc760691e 100644
--- a/_articles/hu/leadership-and-governance.md
+++ b/_articles/hu/leadership-and-governance.md
@@ -73,7 +73,7 @@ Miután létrehoztad a vezetői szerepeket, ne felejtsd el dokumentálni, hogyan
 
 Az olyan eszközök, mint a [Vossibility](https://github.com/icecrime/vossibility-stack) segíthetnek nyilvánosan nyomon követni, hogy ki, mennyivel járul hozzá a projekthez. Az ilyen információk dokumentálása és publikálása megakadályozza azt, hogy a közösség úgy tekintsen a karbantartókra, mint egy szűk, zárt csoportra, akik önkényesen döntenek.
 
-És végül, ha a projekted a GitHub-on van, gondolkozz el azon, hogy a projektedet a személyes fiókodból egy szervezeti fiókba (_Organization account_) migrálod, legalább még egy helyettes adminisztrátor felvételével. A [GitHub szervezeti fiók](https://help.github.com/articles/creating-a-new-organization-account/) segít abban, hogy könnyebben kezeld a jogosultságokat, a kód tárolókat, és több [társtulajdonost](../building-community/#a-projekt-tulajdonjogának-megosztása) beállítva segít megőrizni a projekt örökségét.
+És végül, ha a projekted a GitHub-on van, gondolkozz el azon, hogy a projektedet a személyes fiókodból egy szervezeti fiókba (_Organization account_) migrálod, legalább még egy helyettes adminisztrátor felvételével. A [GitHub szervezeti fiók](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) segít abban, hogy könnyebben kezeld a jogosultságokat, a kód tárolókat, és több [társtulajdonost](../building-community/#a-projekt-tulajdonjogának-megosztása) beállítva segít megőrizni a projekt örökségét.
 
 ## Mikor kell valakinek _commit_ jogot adnom?
 
@@ -81,7 +81,7 @@ Néhányan azt gondolják, hogy mindenkinek, aki hozzájárul a projekthez. Ha e
 
 Másrészről, különösen komplex és nagy projektek esetén, csak azoknak az embereknek célszerű ilyen jogot adni, akik bizonyították elkötelezettségüket a projekt felé. Nincs aranyszabály, hogy melyik a jobb, neked kell eldöntened, hogy számodra mi a megfelelő.
 
-Ha a projekt a GitHub-on van, használhatsz [védett kód ágakat (branch)](https://help.github.com/articles/about-protected-branches/), melyekkel szabályozni tudod, hogy kik és milyen feltételekkel olvaszthatnak be kódot egy kód ágra.
+Ha a projekt a GitHub-on van, használhatsz [védett kód ágakat (branch)](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches), melyekkel szabályozni tudod, hogy kik és milyen feltételekkel olvaszthatnak be kódot egy kód ágra.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index 1b586051801..fcb8afc2d2c 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -28,7 +28,7 @@ Ha nem alkalmazol nyílt forráskódú licencet, akkor mindenki, aki hozzájáru
 
 ## Nyílt forráskódúak a nyilvános GitHub projektek?
 
-Amikor [létrehozol egy új projektet](https://help.github.com/articles/creating-a-new-repository/) a GitHub-on, lehetőséged van megadni, hogy a projekt **private** (privát) vagy **public** (publikus) legyen.
+Amikor [létrehozol egy új projektet](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) a GitHub-on, lehetőséged van megadni, hogy a projekt **private** (privát) vagy **public** (publikus) legyen.
 
 ![Projekt létrehozása](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Szerencsés helyzetben vagy, mert manapság a nyílt forráskódú licencek szab
 
 Az [MIT](https://choosealicense.com/licenses/mit/), az [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), és a [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) a legismertebb nyílt forráskódú licencek, de vannak más lehetőségek is amikből választhatsz. Ezen licencek teljes szövegét és használatuk módját megtalálod a [choosealicense.com](https://choosealicense.com/) oldalon.
 
-Ha új projektet hozol létre a GitHub-on, meg kell adnod, hogy [milyen licencű a projekt](https://help.github.com/articles/open-source-licensing/).
+Ha új projektet hozol létre a GitHub-on, meg kell adnod, hogy [milyen licencű a projekt](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ Alternatív megoldásként, a résztvevők előzetesen (egy kiegészítő hozzá
 
 ## Szükségem van-e kiegészítő hozzájárulási megállapodásra?
 
-Valószínűleg nem. A nyílt forráskódú projektek túlnyomó többsége esetében a nyílt forráskódú licenc implicit módon tartalmazza egyaránt a bejövő (a résztvevőkről) és a kimenő (más hozzájárulók és felhasználók) licencet. Ha a projekt a GitHub-on van, akkor a GitHub Általános Szerződési Feltételei szerint a "bejövő = kimenő" elv [kifejezetten alapértelmezett](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Valószínűleg nem. A nyílt forráskódú projektek túlnyomó többsége esetében a nyílt forráskódú licenc implicit módon tartalmazza egyaránt a bejövő (a résztvevőkről) és a kimenő (más hozzájárulók és felhasználók) licencet. Ha a projekt a GitHub-on van, akkor a GitHub Általános Szerződési Feltételei szerint a "bejövő = kimenő" elv [kifejezetten alapértelmezett](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Egy kiegészítő hozzájárulási megállapodás, amelyet gyakran közreműködői licenc megállapodásnak (CLA) neveznek, adminisztratív munkát generálhat a projektgazdák számára. A projekt és a kivitelezés függvénye, hogy ez mennyi munkát jelent. Egy egyszerű megállapodás megkövetelheti, hogy a közreműködők egy kattintással megerősítsék, hogy megvan a szükséges joguk a nyílt forráskódú projekt licencének megfelelő részvételhez. Egy bonyolultabb megállapodás jogi felülvizsgálatot, és a résztvevők munkáltatójától kapott hozzájárulást is igényelhet.
 
diff --git a/_articles/hu/metrics.md b/_articles/hu/metrics.md
index 2ee70874104..8ac5e4ff910 100644
--- a/_articles/hu/metrics.md
+++ b/_articles/hu/metrics.md
@@ -37,7 +37,7 @@ Mielőtt bárki elkezdené használni a projektedet, vagy részt venne benne, tu
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Ha a munkád a GitHub-on van, [akkor láthatod](https://help.github.com/articles/about-repository-graphs/#traffic) hogy hány ember járt az oldaladon, és hogy honnan érkeztek. A projekt oldaláról, válaszd ki az "Insights", majd a "Traffic" funkciót. Ezen az oldalon a következőket láthatod:
+Ha a munkád a GitHub-on van, [akkor láthatod](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) hogy hány ember járt az oldaladon, és hogy honnan érkeztek. A projekt oldaláról, válaszd ki az "Insights", majd a "Traffic" funkciót. Ezen az oldalon a következőket láthatod:
 
 * **Views:** Megadja, hogy hányszor nézték meg a projekt oldalát.
 
@@ -47,7 +47,7 @@ Ha a munkád a GitHub-on van, [akkor láthatod](https://help.github.com/articles
 
 * **Popular content:** Megadja, hogy a projekted mely részére kíváncsiak a látogatók, lebontva oldalakra és látogatókra.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) szintén segíthet a népszerűség mérésében. Bár a _GitHub stars_ nem szükségszerűen van kapcsolatban azzal, hogy hányan töltötték le vagy használták a projektet, mégis alkalmas arra, hogy mérje azt, hogy mennyi ember érdeklődését keltette fel a munkád.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) szintén segíthet a népszerűség mérésében. Bár a _GitHub stars_ nem szükségszerűen van kapcsolatban azzal, hogy hányan töltötték le vagy használták a projektet, mégis alkalmas arra, hogy mérje azt, hogy mennyi ember érdeklődését keltette fel a munkád.
 
 Érdemes lehet [egyéb helyeken is nyomon követni az elérhetőséget](https://opensource.com/business/16/6/pirate-metrics): például, Google PageRank, hivatkozások a projekt oldaladról vagy hivatkozások más nyílt forráskódú oldalról, vagy weboldalról.
 
diff --git a/_articles/hu/starting-a-project.md b/_articles/hu/starting-a-project.md
index 4449eb7be6d..3cdc104f17c 100644
--- a/_articles/hu/starting-a-project.md
+++ b/_articles/hu/starting-a-project.md
@@ -106,9 +106,9 @@ Nincs tökéletes időpont a forráskód megnyitására. Megnyithatsz egy ötlet
 
 Függetlenül attól, hogy melyik szakaszban döntöd el a projekt forrásának megnyitását, minden projektnek tartalmaznia kell a következő dokumentációt:
 
-* [Nyílt forráskódú licenc](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)
-* [Résztvevőknek útmutató](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Nyílt forráskódú licenc](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Résztvevőknek útmutató](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Magatartási kódex](../code-of-conduct/)
 
 Karbantartóként ezek az összetevők segítenek az elvárásaid közlésében, a résztvevők kezelésében és mindenki jogának a védelmében (beleértve a sajátodat is). Jelentősen növelik az esélyt arra, hogy pozitív tapasztalatokat szerezz.
@@ -183,7 +183,7 @@ Idővel további gyakori kérdéseket adhatsz hozzá a CONTRIBUTING fájlhoz. Ez
 
 További segítségért a CONTRIBUTING írásához, nézd meg @nayafia [részvételi útmutató űrlapját](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) vagy a @mozilla's ["Hogyan építs CONTRIBUTING.md-t?"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-A CONTRIBUTING állományra hivatkozhatsz a README állományból, így az emberek azonnal látják azt. Ha [elhelyezed a CONTRIBUTING állományt a projekt alatt](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), akkor a GitHub automatikusan linkelni fogja azt, ha valaki hibát jelent, vagy beolvasztási kérést hoz létre.
+A CONTRIBUTING állományra hivatkozhatsz a README állományból, így az emberek azonnal látják azt. Ha [elhelyezed a CONTRIBUTING állományt a projekt alatt](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), akkor a GitHub automatikusan linkelni fogja azt, ha valaki hibát jelent, vagy beolvasztási kérést hoz létre.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -256,7 +256,7 @@ Nem kell stílus útmutatót írni a projekthez, amikor éppen elkezdted, vagy h
 
 ## Indulás előtti ellenőrző lista
 
-Készen állsz a nyílt forráskódú projektre? Itt egy ellenőrzőlista, amely ebben segít. Leellenőrizted az összes pontot? Akkor készen állsz! [Válaszd a "publish" linket](https://help.github.com/articles/making-a-private-repository-public/) és indulhat a publikálás!
+Készen állsz a nyílt forráskódú projektre? Itt egy ellenőrzőlista, amely ebben segít. Leellenőrizted az összes pontot? Akkor készen állsz! [Válaszd a "publish" linket](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) és indulhat a publikálás!
 
 **Dokumentáció**
 
diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md
index 4ab11ff70c2..f97b2691ca1 100644
--- a/_articles/id/best-practices.md
+++ b/_articles/id/best-practices.md
@@ -213,7 +213,7 @@ Salah satu cara penting yang bisa dilakukan untuk melakukan otomatisasi proyek A
 
 Pengujian otomatis membantu kontributor bahwa mereka tidak merusak apapun. Pengujian otomatis juga mempermudah Anda untuk melakukan review dan menerima kontribusi dengan cepat. Semakin cepat Anda merespon, maka komunitas Anda juga akan semakin tertarik.
 
-Lakukan pengaturan untuk pengujian otomatis yang akan berjalan pada semua kontribusi yang masuk, dan pastikan pengujian Anda dapat dilakukan dengan mudah oleh kontributor secara lokal. Pastikan bahwa semua kontribusi kode melewati pengujian Anda sebelum mereka bisa diajukan. Anda perlu menetapkan standar minimal kualitas dari semua pengajuan. [Penggunaan pengujian status](https://help.github.com/articles/about-required-status-checks/) pada GitHub dapat membantu memastikan tidak ada perubahan yang disetujui tanpa melalui pengujian Anda.
+Lakukan pengaturan untuk pengujian otomatis yang akan berjalan pada semua kontribusi yang masuk, dan pastikan pengujian Anda dapat dilakukan dengan mudah oleh kontributor secara lokal. Pastikan bahwa semua kontribusi kode melewati pengujian Anda sebelum mereka bisa diajukan. Anda perlu menetapkan standar minimal kualitas dari semua pengajuan. [Penggunaan pengujian status](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) pada GitHub dapat membantu memastikan tidak ada perubahan yang disetujui tanpa melalui pengujian Anda.
 
 Jika Anda menambahkan pengujian, pastikan untuk menjelaskan bagaimana mereka bekerja pada dokumen CONTRIBUTING.
 
diff --git a/_articles/id/building-community.md b/_articles/id/building-community.md
index 01235e4efda..274fb1f7e06 100644
--- a/_articles/id/building-community.md
+++ b/_articles/id/building-community.md
@@ -166,7 +166,7 @@ Cari cara untuk bisa berbagi kepemilikan dengan komunitas Anda sebanyak mungkin.
 
 * **Berikan setiap kontributor akses commit.** @felixge menemukan bahwa hal ini membuat orang lain [lebih tertarik untuk memperbaiki perbaikan mereka](https://felixge.de/2013/03/11/the-pull-request-hack.html), dan dia juga menemukan pengelola baru untuk proyek yang tidak dia kelola selama beberapa waktu.
 
-* Jika proyek Anda berada pada GitHub, **pindahkan proyek Anda dari akun personal ke [Organisasi](https://help.github.com/articles/creating-a-new-organization-account/)** dan tambahkan paling tidak satu admin cadangan. Organisasi mempermudah pekerjaan kolaborasi dengan kolaborator eksternal.
+* Jika proyek Anda berada pada GitHub, **pindahkan proyek Anda dari akun personal ke [Organisasi](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** dan tambahkan paling tidak satu admin cadangan. Organisasi mempermudah pekerjaan kolaborasi dengan kolaborator eksternal.
 
 Kenyataannya adalah [sebagian besar proyek hanya memiliki](https://peerj.com/preprints/1233/) satu atau dua pengeloa yang melakukan sebagian besar pekerjaan. Semakin besar proyek Anda, dan semakin besar komunitas Anda, semakin mudah untuk menemukan bantuan.
 
diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md
index fe576995692..6c29921fda4 100644
--- a/_articles/id/how-to-contribute.md
+++ b/_articles/id/how-to-contribute.md
@@ -433,7 +433,7 @@ Jika Anda tidak bisa menemukan ide Anda dimanapun, Anda siap untuk bergerak. Jik
 
 Sebelum Anda membuka sebuah laporan masalah atau melakukan pull request, periksa dokumen kontribusi proyek (biasanya pada dokumen bernama CONTRIBUTING, atau pada README), untuk melihat apakah Anda perlu mencantumkan informasi yang spesifik. Sebagai contoh, mereka mungkin meminta Anda untuk mengikuti sebuah template, atau mengharuskan Anda untuk menggunakan perangkat pengujian.
 
-Jika Anda hendak melakukan kontribusi yang cukup substansial, buatlah sebuah laporan masalah sebelum memulai bekerja. Sangatlah bermanfaat untuk mengamati proyek dalam kurun waktu tertentu (pada GitHub, [Anda bisa memilih menu "Watch"](https://help.github.com/articles/watching-repositories/) untuk mendapatkan notifikasi dari semua percakapan), dan mengenal anggota komunitas, sebelum memulai pekerjaan yang belum tentu akan diterima.
+Jika Anda hendak melakukan kontribusi yang cukup substansial, buatlah sebuah laporan masalah sebelum memulai bekerja. Sangatlah bermanfaat untuk mengamati proyek dalam kurun waktu tertentu (pada GitHub, [Anda bisa memilih menu "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) untuk mendapatkan notifikasi dari semua percakapan), dan mengenal anggota komunitas, sebelum memulai pekerjaan yang belum tentu akan diterima.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -468,7 +468,7 @@ Sebuah pull request tidak harus mencerminkan sebuah pekerjaan yang sudah selesai
 
 Jika proyek berada pada GitHub, berikut cara untuk membuka pull request:
 
-* **[Fork repositori](https://guides.github.com/activities/forking/)** dan clone secara lokal. Hubungkan lokal Anda dengan repositori asli "_upstream_" dengan menambahkannya sebagai remote. Pull semua perubahan dari "upstream" secara berkala sehingga Anda selalu _up to date_ dan ketika Anda mengajukan pull request Anda, _merge conflict_ akan lebih jarang terjadi. (Lihat instruksi lebih detail [disini](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork repositori](https://guides.github.com/activities/forking/)** dan clone secara lokal. Hubungkan lokal Anda dengan repositori asli "_upstream_" dengan menambahkannya sebagai remote. Pull semua perubahan dari "upstream" secara berkala sehingga Anda selalu _up to date_ dan ketika Anda mengajukan pull request Anda, _merge conflict_ akan lebih jarang terjadi. (Lihat instruksi lebih detail [disini](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Membuat sebuah branch](https://guides.github.com/introduction/flow/)** untuk hasil pengeditan Anda.
 * **Referensikan laporan masalah yang berhubungan** atau dokumentasi pendukung pada PR Anda (Misalnya. "Menutup #37.")
 * **Sertakan tangkapan layar sebelum dan sesudah** jika perubahan Anda meliputi perubahan pada HTML/CSS. Tarik dan letakkan gambar citra pada bagian _body_ dari pull request Anda.
diff --git a/_articles/id/leadership-and-governance.md b/_articles/id/leadership-and-governance.md
index 96d2b0d3bf8..f65196edf7a 100644
--- a/_articles/id/leadership-and-governance.md
+++ b/_articles/id/leadership-and-governance.md
@@ -73,7 +73,7 @@ Setelah Anda mendefinisikan peran pemimpin Anda, jangan lupa untuk mendokumentas
 
 Peralatan seperti [Vossibility](https://github.com/icecrime/vossibility-stack) bisa membantu Anda melacak siapa yang (tidak) memberikan kontribusi pada proyek. Mendokumentasikan informasi ini akan menghindari persepsi komunitas bahwa pengelola mengambil keputusan secara pribadi.
 
-Akhirnya, jika proyek Anda berada pada GitHub, pertimbangkan untuk memindahkan proyek Anda dari akun prbadi pada "Organization" dan menambahkan paling tidak satu admin cadangan. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) membuat pengelolaan hak akses dan banyak repository menjadi lebih mudah dan juga menjaga proyek Anda melalui [berbagi kepemilikan](../building-community/#berbagi-kepemilikan-dari-proyek-anda).
+Akhirnya, jika proyek Anda berada pada GitHub, pertimbangkan untuk memindahkan proyek Anda dari akun prbadi pada "Organization" dan menambahkan paling tidak satu admin cadangan. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) membuat pengelolaan hak akses dan banyak repository menjadi lebih mudah dan juga menjaga proyek Anda melalui [berbagi kepemilikan](../building-community/#berbagi-kepemilikan-dari-proyek-anda).
 
 ## Kapan saya harus memberikan akses commit kepada seseorang?
 
@@ -81,7 +81,7 @@ Beberapa orang berpikir bahwa Anda perlu memberikan akses commit pada semua oran
 
 Disisi lain, terutama untuk proyek yang besar dan kompleks, Anda mungkin hanya akan memberikan akses commit pada orang-orang yang mendemonstrasikan komitmen mereka Tidak ada cara yang paling benar untuk melakukan hal ini - lakukan apa yang Anda rasa paling baik!
 
-Jika proyek Anda berada pada GitHub, Anda bisa menggunakan [protected branches](https://help.github.com/articles/about-protected-branches/) untuk mengelola siapa saja yang boleh mengirimkan pada branch tertentu, dan pada kondisi apa.
+Jika proyek Anda berada pada GitHub, Anda bisa menggunakan [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) untuk mengelola siapa saja yang boleh mengirimkan pada branch tertentu, dan pada kondisi apa.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index 426937da942..291032e424e 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -28,7 +28,7 @@ Akhirnya, proyek Anda mungkin memiliki ketergantungan dengan kebutuhan lisensi y
 
 ## Apakah proyek publik GitHub open source?
 
-Ketika Anda [membuat proyek baru](https://help.github.com/articles/creating-a-new-repository/) pada GitHub, Anda memiliki opsi untuk membuat repositori **private** atau **public**.
+Ketika Anda [membuat proyek baru](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) pada GitHub, Anda memiliki opsi untuk membuat repositori **private** atau **public**.
 
 ![create repository](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Anda beruntung, karena saat ini lisensi open source sudah terstandarisasi dan mu
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), dan [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) adalah lisensi open source yang paling populer, tetapi terdapat opsi lain yang dapat Anda pilih. Anda bisa menemukan teks lengkap dari lisensi tersebut, termasuk instruksi bagaimana menggunakannya pada [choosealicense.com](https://choosealicense.com/).
 
-Ketika Anda menciptakan proyek baru pada GitHub, Anda akan [diminta untuk menambahkan lisensi](https://help.github.com/articles/open-source-licensing/).
+Ketika Anda menciptakan proyek baru pada GitHub, Anda akan [diminta untuk menambahkan lisensi](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ Alternatif lain, Anda bisa mendapatkan persetujuan kontributor di awal (melalui
 
 ## Apakah proyek saya membutuhkan perjanjian kontributor tambahan?
 
-Kemungkinan tidak. Untuk sebagian besar proyek open source, lisensi open source secara implisit berfungsi sebagai lisensi inbound (dari kontributor) dan outbound (bagi kontributor dan pengguna lainnya). Jika proyek Anda berada pada GitHub, Perjanjian Layanan GitHub membuat aturan "inbound=outbound" [default secara eksplisit](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Kemungkinan tidak. Untuk sebagian besar proyek open source, lisensi open source secara implisit berfungsi sebagai lisensi inbound (dari kontributor) dan outbound (bagi kontributor dan pengguna lainnya). Jika proyek Anda berada pada GitHub, Perjanjian Layanan GitHub membuat aturan "inbound=outbound" [default secara eksplisit](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Sebuah perjanjian kontributor tambahan -- seringkali disebut Contributor License Agreement (CLA) -- bisa menimbulkan pekerjaan administratif tambahan bagi pengelola proyek. Seberapa banyak pekerjaan tersebut tergantung dari proyek dan implementasinya. Sebuah perjanjian yang sederhana mungkin meminta kontributor untuk melakukan konfirmasi dengan satu klik, bahwa mereka memiliki hak yang cukup untuk berkontribusi dibawah lisensi open source. Perjanjian yang lebih kompleks mungkin membutuhkan review hukum dan tanda tangan dari perusahaan yang memperkerjakan kontributor tersebut.
 
diff --git a/_articles/id/metrics.md b/_articles/id/metrics.md
index adb448bfccf..25045128ffb 100644
--- a/_articles/id/metrics.md
+++ b/_articles/id/metrics.md
@@ -37,7 +37,7 @@ Sebelum setiap orang bisa menggunakan atau berkontribusi pada proyek Anda, merek
 
 ![traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Jika proyek Anda berada di GitHub, [Anda dapat melihat](https://help.github.com/articles/about-repository-graphs/#traffic) berapa banyak orang yang sampai pada proyek Anda dan darimana mereka berasal. Dari halaman proyek Anda, klik "Graphs", lalu "Traffic". Pada halaman ini, Anda bisa melihat:
+Jika proyek Anda berada di GitHub, [Anda dapat melihat](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) berapa banyak orang yang sampai pada proyek Anda dan darimana mereka berasal. Dari halaman proyek Anda, klik "Graphs", lalu "Traffic". Pada halaman ini, Anda bisa melihat:
 
 * **Total pageviews:** Menginformasikan berapa banyak proyek Anda dilihat
 
@@ -47,7 +47,7 @@ Jika proyek Anda berada di GitHub, [Anda dapat melihat](https://help.github.com/
 
 * **Popular content:** Menginformasikan kemana pengunjung Anda melakuan navigasi pada proyek Anda, dilihat dari pageviews dan pengunjung unik.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) juga bisa membantu menyediakan pengukuran dasar dari popularitas. Meskipun GitHub stars tidak serta-merta mengkorelasikan pada jumlah download dan penggunaan, informasi dari GitHub stars dapat menginformasikan berapa banyak orang yang memperhatikan pekerjaan Anda.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) juga bisa membantu menyediakan pengukuran dasar dari popularitas. Meskipun GitHub stars tidak serta-merta mengkorelasikan pada jumlah download dan penggunaan, informasi dari GitHub stars dapat menginformasikan berapa banyak orang yang memperhatikan pekerjaan Anda.
 
 Anda mungkin ingin [melacak temuan pada tempat khusus](https://opensource.com/business/16/6/pirate-metrics): misalnya, Google PageRank, trafik referensi dari halaman web proyek Anda, atau referensi dari proyek open source dan website.
 
diff --git a/_articles/id/starting-a-project.md b/_articles/id/starting-a-project.md
index 9140381a3e7..f181dd00ed5 100644
--- a/_articles/id/starting-a-project.md
+++ b/_articles/id/starting-a-project.md
@@ -113,9 +113,9 @@ Secara umum, Anda harus membuka proyek Anda menjadi ketika Anda merasa nyaman ke
 
 Tidak perduli pada tahap mana Anda memutuskan untuk membuka proyek Anda, setiap proyek sebaiknya menyediakan dokumentasi berikut:
 
-* [Lisensi open source](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)
-* [Panduan berkontribusi](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Lisensi open source](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Panduan berkontribusi](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Kode etik](../code-of-conduct/)
 
 Sebagai pengelola, komponen-komponen tersebut akan membantu Anda mengkomunikasikan ekspektasi, mengelola kontribusi, dan menjaga hak legal dari setiap orang (termasuk Anda sendiri). Dokumen-dokumen tersebut akan meningkatkan peluang Anda secara signifikan untuk mendapatkan pengalaman yang positif.
@@ -189,7 +189,7 @@ Seiring dengan berjalannya waktu, Anda bisa menambahkan pertanyaan yang paling s
 
 Untuk bantuan tentang penulisan dokumen CONTRIBUTING, silahkan lihat  [template panduan berkontribusi](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) milik @nayafia atau ["Bagaimana Membangun Dokumen CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) milik @mozilla.
 
-Hubungkan dokumen CONTRIBUTING dari README, sehingga lebih banyak orang yang melihatnya. Jika Anda [meletakkan dokumen CONTRIBUTING pada repositori proyek](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub akan secara otomatis menghubungkan ke dokumen Anda ketika seorang kontributor membuat sebuah laporan masalah atau membuat pull request.
+Hubungkan dokumen CONTRIBUTING dari README, sehingga lebih banyak orang yang melihatnya. Jika Anda [meletakkan dokumen CONTRIBUTING pada repositori proyek](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub akan secara otomatis menghubungkan ke dokumen Anda ketika seorang kontributor membuat sebuah laporan masalah atau membuat pull request.
 
 ![panduan kontribusi](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -262,7 +262,7 @@ Tidaklah penting untuk menuliskan gaya penulisan untuk proyek Anda ketika Anda b
 
 ## Daftar checklist pra-rilis
 
-Sudah siap untuk membuat proyek Anda open source ? Berikut daftar checklist untuk membantu. Anda sudah menyelesaikan semua kotak? Anda sudah siap! [Klik"publish"](https://help.github.com/articles/making-a-private-repository-public/) dan tepuklah diri Anda sendiri.
+Sudah siap untuk membuat proyek Anda open source ? Berikut daftar checklist untuk membantu. Anda sudah menyelesaikan semua kotak? Anda sudah siap! [Klik"publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) dan tepuklah diri Anda sendiri.
 
 **Dokumentasi**
 
diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md
index 15064842755..addb535eb28 100644
--- a/_articles/it/best-practices.md
+++ b/_articles/it/best-practices.md
@@ -214,7 +214,7 @@ Uno dei modi più importanti per automatizzare il tuo progetto è attraverso i t
 I test aiutano i contributori a sentirsi sicuri che non romperanno nulla. Inoltre, facilitano la revisione e l'accettazione rapida dei contributi. Più sei ricettivo, più sarai coinvolto. sii la tua comunità.
 
 Imposta test automatizzati per eseguire tutti i contributi in arrivo e garantire che possano essere eseguiti localmente dai contributori. È necessario che tutti i contributi al codice superino i test prima di poter essere inviati. Contribuirà a stabilire uno standard minimo di qualità per tutte le applicazioni.
-[Sono necessari controlli sullo stato](https://help.github.com/articles/about-required-status-checks/) su GitHub può aiutare a garantire che nessuna modifica venga unita senza prima eseguire i test.
+[Sono necessari controlli sullo stato](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) su GitHub può aiutare a garantire che nessuna modifica venga unita senza prima eseguire i test.
 
 Se aggiungi test, assicurati di spiegare come funzionano nel tuo file CONTRIBUTING.
 
diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md
index 94ec2a38069..2e842ca8e8a 100644
--- a/_articles/it/building-community.md
+++ b/_articles/it/building-community.md
@@ -28,7 +28,7 @@ Inizia con la tua documentazione:
 
 * **Semplifica le cose per coloro che hanno bisogno di utilizzare il progetto.** [Documento README intuitivo](../starting-a-project/#scrivi-readme) e chiari esempi di codice lo renderanno facile da usare. È un inizio facile per chiunque si imbatta nel tuo progetto.
 * **Spiega chiaramente come contribuire** utilizzando [CONTRIBUTING file](../starting-a-project/#scrivi-le-linee-guida-per-il-tuo-contributo) e mantieni aggiornati i tuoi problemi.
-* **Buone prime edizioni**: per aiutare i nuovi contributori a iniziare, pensa chiaramente a [sottolineare gli argomenti che sono abbastanza semplici da poter essere gestiti da un principiante](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub mostrerà quindi questi problemi in vari punti della piattaforma, aumentando i contributi utili e riducendo la pressione degli utenti che affrontano questioni troppo difficili per il loro livello.
+* **Buone prime edizioni**: per aiutare i nuovi contributori a iniziare, pensa chiaramente a [sottolineare gli argomenti che sono abbastanza semplici da poter essere gestiti da un principiante](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub mostrerà quindi questi problemi in vari punti della piattaforma, aumentando i contributi utili e riducendo la pressione degli utenti che affrontano questioni troppo difficili per il loro livello.
 
 [Sondaggio open source GitHub 2017](http://opensourcesurvey.org/2017/) ha dimostrato che la documentazione incompleta o confusa è il problema più grande per gli utenti open source. Una buona documentazione invita le persone a interagire con il tuo progetto. Alla fine, qualcuno aprirà un problema o una richiesta. Usa queste interazioni come opportunità per spostarle lungo la canalizzazione.
 
@@ -167,7 +167,7 @@ Vedi se riesci a trovare modi per condividere il più possibile la proprietà co
 
 * **Concedi l'accesso al commit a ogni collaboratore.** @felixge ha scoperto che rendeva le persone [più entusiaste di migliorare le proprie soluzioni](https://felixge.de/2013/03/11/the-pull-request-hack.html) e ha anche trovato nuovi manutentori per progetti su cui non lavorava da un po'.
 
-* Se il tuo progetto è su GitHub, **sposta il tuo progetto dal tuo account personale a [Organizzazione](https://help.github.com/articles/creating-a-new-organization-account/)** e aggiungilo a almeno un amministratore di backup. Le organizzazioni facilitano il lavoro di progetto con collaboratori esterni.
+* Se il tuo progetto è su GitHub, **sposta il tuo progetto dal tuo account personale a [Organizzazione](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** e aggiungilo a almeno un amministratore di backup. Le organizzazioni facilitano il lavoro di progetto con collaboratori esterni.
 
 La realtà è che [la maggior parte dei progetti ha solo](https://peerj.com/preprints/1233/) uno o due manutentori che svolgono la maggior parte del lavoro. Più grande è il tuo progetto e la tua comunità, più facile sarà trovare aiuto.
 
diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md
index 932429a3946..91f678541bd 100644
--- a/_articles/it/how-to-contribute.md
+++ b/_articles/it/how-to-contribute.md
@@ -447,7 +447,7 @@ Se non riesci a trovare la tua idea altrove, sei pronto a fare una mossa. Se il
 
 Prima di aprire un problema o una richiesta pull, controlla i documenti che contribuiscono al progetto (di solito un file chiamato CONTRIBUTING o nel README) per vedere se è necessario includere qualcosa di specifico. Ad esempio, potrebbero chiederti di seguire uno schema o richiederti di utilizzare dei test.
 
-Se vuoi dare un contributo significativo, apri un issue da chiedere prima di lavorarci. È utile guardare il progetto per un po' (su GitHub, [puoi fare clic su "Guarda"](https://help.github.com/articles/watching-repositories/) per ricevere una notifica di tutte le conversazioni) e accedere a conoscere i membri della comunità prima di svolgere lavori che potrebbero non essere accettati.
+Se vuoi dare un contributo significativo, apri un issue da chiedere prima di lavorarci. È utile guardare il progetto per un po' (su GitHub, [puoi fare clic su "Guarda"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) per ricevere una notifica di tutte le conversazioni) e accedere a conoscere i membri della comunità prima di svolgere lavori che potrebbero non essere accettati.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -482,7 +482,7 @@ Una richiesta pull non deve rappresentare un lavoro completato. Di solito è meg
 
 Se il progetto è su GitHub, ecco come inviare una richiesta pull:
 
-* **[Fork il repository](https://guides.github.com/activities/forking/)** e clonalo localmente. Connetti il ​​tuo locale al repository upstream originale aggiungendolo come remoto. Estrai spesso le modifiche da "upstream" per rimanere aggiornato, quindi quando invii la tua richiesta di pull, i conflitti di unione saranno meno probabili. (Vedi istruzioni più dettagliate [qui](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork il repository](https://guides.github.com/activities/forking/)** e clonalo localmente. Connetti il ​​tuo locale al repository upstream originale aggiungendolo come remoto. Estrai spesso le modifiche da "upstream" per rimanere aggiornato, quindi quando invii la tua richiesta di pull, i conflitti di unione saranno meno probabili. (Vedi istruzioni più dettagliate [qui](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Crea un ramo](https://guides.github.com/introduction/flow/)** per le tue modifiche.
 * **Elenca eventuali problemi rilevanti** o documentazione di supporto nel tuo PR (ad esempio "Chiude n. 37.")
 * **Includi screenshot prima e dopo** se le modifiche comportano differenze HTML/CSS. Trascina e rilascia le immagini nel corpo della tua richiesta pull.
diff --git a/_articles/it/leadership-and-governance.md b/_articles/it/leadership-and-governance.md
index 42f5eb40749..fa5513856c6 100644
--- a/_articles/it/leadership-and-governance.md
+++ b/_articles/it/leadership-and-governance.md
@@ -73,7 +73,7 @@ Una volta stabiliti i ruoli di leadership, assicurati di documentare come le per
 
 Strumenti come [Vossibility](https://github.com/icecrime/vossibility-stack) possono aiutarti a tenere traccia pubblicamente chi sta (o non sta) contribuendo al progetto. Documentare queste informazioni evita la percezione della comunità secondo cui i manutentori sono una cricca che prende le proprie decisioni in privato.
 
-Infine, se il tuo progetto è su GitHub, valuta la possibilità di spostare il progetto dal tuo account personale a un'organizzazione e di aggiungere almeno un amministratore di backup. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) semplifica la gestione delle autorizzazioni e di più repository e protegge l'eredità del tuo progetto tramite [proprietà condivisa](../building-community/#condividi-la-proprietà-del-tuo-progetto).
+Infine, se il tuo progetto è su GitHub, valuta la possibilità di spostare il progetto dal tuo account personale a un'organizzazione e di aggiungere almeno un amministratore di backup. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) semplifica la gestione delle autorizzazioni e di più repository e protegge l'eredità del tuo progetto tramite [proprietà condivisa](../building-community/#condividi-la-proprietà-del-tuo-progetto).
 
 ## Quando dovrei dare a qualcuno l'accesso per impegnarsi?
 
@@ -81,7 +81,7 @@ Alcune persone pensano che dovresti dare accesso al coinvolgimento a tutti color
 
 D'altra parte, soprattutto per progetti più grandi e complessi, potresti voler concedere l'accesso al coinvolgimento solo alle persone che hanno dimostrato il proprio impegno. Non esiste un modo giusto per farlo: fai ciò che ti fa sentire più a tuo agio!
 
-Se il tuo progetto è su GitHub, puoi utilizzare [rami protetti](https://help.github.com/articles/about-protected-branches/) per gestire chi può puntare a un particolare ramo e in quali circostanze.
+Se il tuo progetto è su GitHub, puoi utilizzare [rami protetti](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) per gestire chi può puntare a un particolare ramo e in quali circostanze.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/it/legal.md b/_articles/it/legal.md
index 92db8748b90..99c26c104f5 100644
--- a/_articles/it/legal.md
+++ b/_articles/it/legal.md
@@ -28,7 +28,7 @@ Infine, il tuo progetto potrebbe avere dipendenze con requisiti di licenza di cu
 
 ## Публичните GitHub проекти с отворен код ли са?
 
-Quando [crei nuovo progetto](https://help.github.com/articles/creating-a-new-repository/) su GitHub, hai la possibilità di rendere il repository **privato** o **pubblico**.
+Quando [crei nuovo progetto](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) su GitHub, hai la possibilità di rendere il repository **privato** o **pubblico**.
 
 ![Crea un archivio](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Sei fortunato perché oggi le licenze open source sono standardizzate e facili d
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) e [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sono [licenze open source popolari](https://innovationgraph.github.com/global-metrics/licenses), ma ci sono altre opzioni tra cui scegliere. È possibile trovare il testo completo di queste licenze e le istruzioni su come utilizzarle all'indirizzo [choosealicense.com](https://choosealicense.com/).
 
-Quando crei un nuovo progetto su GitHub, ti verrà [chiesto di aggiungere una licenza](https://help.github.com/articles/open-source-licensing/).
+Quando crei un nuovo progetto su GitHub, ti verrà [chiesto di aggiungere una licenza](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -90,7 +90,7 @@ In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche
 
 ## Il mio progetto necessita di un contratto di collaborazione aggiuntivo?
 
-Probabilmente no. Per la stragrande maggioranza dei progetti open source, la licenza open source funge implicitamente sia da licenza in entrata (dai contributori) che da licenza in uscita (ad altri contributori e utenti). Se il tuo progetto è su GitHub, i Termini di servizio di GitHub rendono "inbound=outbound" [esplicito per impostazione predefinita](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributi-sotto-licenza-repository).
+Probabilmente no. Per la stragrande maggioranza dei progetti open source, la licenza open source funge implicitamente sia da licenza in entrata (dai contributori) che da licenza in uscita (ad altri contributori e utenti). Se il tuo progetto è su GitHub, i Termini di servizio di GitHub rendono "inbound=outbound" [esplicito per impostazione predefinita](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Un ulteriore contratto di collaborazione, spesso chiamato Contributor License Agreement (CLA), può creare lavoro amministrativo per i manutentori del progetto. La quantità di lavoro aggiunta da un accordo dipende dal progetto e dall'implementazione. Un tipico accordo potrebbe richiedere ai contributori di confermare con un clic di possedere i diritti necessari per contribuire secondo la licenza open source del progetto. Un accordo più complesso può richiedere la revisione legale e la firma da parte dei datori di lavoro dei contributori.
 
diff --git a/_articles/it/metrics.md b/_articles/it/metrics.md
index 08716db858f..110111d259a 100644
--- a/_articles/it/metrics.md
+++ b/_articles/it/metrics.md
@@ -37,7 +37,7 @@ Prima che chiunque possa utilizzare o contribuire al tuo progetto, deve sapere c
 
 ![Grafico del traffico](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Se il tuo progetto è ospitato su GitHub, [puoi vedere](https://help.github.com/articles/about-repository-graphs/#traffic) quante persone arrivano al tuo progetto e da dove provengono . Dalla pagina del tuo progetto, fai clic su Approfondimenti, quindi su Traffico. In questa pagina puoi vedere:
+Se il tuo progetto è ospitato su GitHub, [puoi vedere](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) quante persone arrivano al tuo progetto e da dove provengono . Dalla pagina del tuo progetto, fai clic su Approfondimenti, quindi su Traffico. In questa pagina puoi vedere:
 
 * **Visualizzazioni di pagina totali:** indica quante volte il tuo progetto è stato visualizzato
 
@@ -47,7 +47,7 @@ Se il tuo progetto è ospitato su GitHub, [puoi vedere](https://help.github.com/
 
 * **Contenuti popolari:** indica dove stanno andando i visitatori nel tuo progetto, suddivisi per visualizzazioni di pagina e visitatori unici.
 
-[Le stelle di GitHub](https://help.github.com/articles/about-stars/) possono anche aiutare a fornire una misura di base della popolarità. Anche se le star di GitHub non sono necessariamente legate ai download e all'utilizzo, possono dirti quante persone prestano attenzione al tuo lavoro.
+[Le stelle di GitHub](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) possono anche aiutare a fornire una misura di base della popolarità. Anche se le star di GitHub non sono necessariamente legate ai download e all'utilizzo, possono dirti quante persone prestano attenzione al tuo lavoro.
 
 Potresti anche voler [monitorare la rilevabilità di posizioni specifiche](https://opensource.com/business/16/6/pirate-metrics): ad esempio, Google PageRank, traffico proveniente da referral dal sito web del tuo progetto o referral da altri progetti o siti web open source.
 
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
index 07e871686c7..cff6008b39f 100644
--- a/_articles/it/starting-a-project.md
+++ b/_articles/it/starting-a-project.md
@@ -106,9 +106,9 @@ In generale, dovresti aprire il tuo progetto quando ti senti a tuo agio con gli
 
 Non importa in quale fase decidi di aprire il tuo progetto, ogni progetto deve includere la seguente documentazione:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 In qualità di sostenitore, questi componenti ti aiuteranno a comunicare le aspettative, a gestire i contributi e a proteggere i diritti legali di tutti (inclusi i tuoi). Aumentano notevolmente le tue possibilità di un'esperienza positiva.
@@ -181,7 +181,7 @@ Nel tempo, potresti aggiungere altre domande frequenti al tuo file CONTRIBUTING.
 
 Per ulteriore assistenza nella scrittura del file CONTRIBUTING, consulta @nayafia [modello guida per la collaborazione](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) o @mozilla ["Come creare CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Collega il tuo file CONTRIBUTE dal tuo README in modo che più persone possano vederlo. Se [posiziona il file CONTRIBUTING nel repository del tuo progetto](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub si collegherà automaticamente al tuo file quando un collaboratore crea un problema o apre una richiesta pull.
+Collega il tuo file CONTRIBUTE dal tuo README in modo che più persone possano vederlo. Se [posiziona il file CONTRIBUTING nel repository del tuo progetto](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub si collegherà automaticamente al tuo file quando un collaboratore crea un problema o apre una richiesta pull.
 
 ![Linee guida per i contributi](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -254,7 +254,7 @@ Non è necessario scrivere una guida di stile per il tuo progetto quando hai app
 
 ## La tua lista di controllo pre-lancio
 
-Pronto per aprire il tuo progetto? Ecco una lista di controllo per aiutarti. Seleziona tutte le caselle? Sei pronto per andare! [Fai clic su "pubblica"](https://help.github.com/articles/making-a-private-repository-public/) e datti una pacca sulla spalla.
+Pronto per aprire il tuo progetto? Ecco una lista di controllo per aiutarti. Seleziona tutte le caselle? Sei pronto per andare! [Fai clic su "pubblica"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) e datti una pacca sulla spalla.
 
 **Documentazione**
 
diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md
index d1aa3c43487..3891efcb7cb 100644
--- a/_articles/ja/best-practices.md
+++ b/_articles/ja/best-practices.md
@@ -213,7 +213,7 @@ related:
 
 テストがあることで、コントリビューターは何一つ壊していない事を自信を持って確認することができます。また、あなたにとっても、コントリビュートをすばやくレビューし取り込みやすくなります。より早く反応すればするほど、コミュニティもより活発になるのです。
 
-全てのコントリビュートに対してテストを自動的に実行するように設定し、またコントリビューターがローカルで簡単にテストを実行できるようにしておきましょう。コントリビュートが提出される前に全てのテストが成功している事を要求しましょう。こうすることで、全てのコントリビュートが提出される前に、最低限の品質基準を設けることができるようになります。 GitHub の [Required status checks](https://help.github.com/articles/about-required-status-checks/) 機能を使うことで、テストが成功していない変更はマージされないよう保証することができます。
+全てのコントリビュートに対してテストを自動的に実行するように設定し、またコントリビューターがローカルで簡単にテストを実行できるようにしておきましょう。コントリビュートが提出される前に全てのテストが成功している事を要求しましょう。こうすることで、全てのコントリビュートが提出される前に、最低限の品質基準を設けることができるようになります。 GitHub の [Required status checks](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) 機能を使うことで、テストが成功していない変更はマージされないよう保証することができます。
 
 テストを追加したら、 CONTRIBUTING ファイルでテストがどう実行されるかを説明しましょう。
 
diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md
index 22a34b08a22..99841dc16bc 100644
--- a/_articles/ja/building-community.md
+++ b/_articles/ja/building-community.md
@@ -166,7 +166,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
 
 * **全てのコントリビューターにコミット権限を与えよう。** @felixge はこれによって人々が [パッチに磨きをかけることによりワクワクするようになる](https://felixge.de/2013/03/11/the-pull-request-hack.html)ことに気づき、更にしばらくの間取り組んでいなかったプロジェクトの新しいメンテナーを見つけることさえできたのです。
 
-* もしプロジェクトが GitHub 上にあるのであれば、 **プロジェクトをあなた個人のアカウントから [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** に移し、最低でも一人代わりの管理者を追加しましょう。 Organization によって外部の協力者と一緒にプロジェクト上での作業をしやすくなります。
+* もしプロジェクトが GitHub 上にあるのであれば、 **プロジェクトをあなた個人のアカウントから [Organization](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** に移し、最低でも一人代わりの管理者を追加しましょう。 Organization によって外部の協力者と一緒にプロジェクト上での作業をしやすくなります。
 
 実際のところ、[ほとんどのプロジェクトはたった](https://peerj.com/preprints/1233/) 一人か二人のメンテナーしかおらず、彼らがほとんどの作業を行っています。プロジェクトやコミュニティが大きくなるほど、協力者を見つけるのがより簡単になります。
 
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index baf923ea5a2..8b26f23c004 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -433,7 +433,7 @@ master ブランチのコミットアクティビティをみてみましょう
 
 イシューやプルリクエストをオープンする前に、そのプロジェクトのコントリビュートの方法についてのドキュメント（大抵は CONTRIBUTING と呼ばれるファイルや README の中にあります）を確認し、なにか特定の情報を含める必要があるか確かめましょう。例えば、あなたはテンプレートを使ったり、テストを実行する必要があるかもしれません。
 
-もしあなたが大きなコントリビュートをしたいのであれば、その仕事に取り掛かる前にイシューをオープンしましょう。受け入れられないかもしれない仕事に取り掛かる前に、暫くの間そのプロジェクトをウォッチし（ GitHub では、 ["Watch" をクリックすることで](https://help.github.com/articles/watching-repositories/) 全ての会話の通知を受け取ることができます)、コミュニティメンバーを知ることは役に立つでしょう。
+もしあなたが大きなコントリビュートをしたいのであれば、その仕事に取り掛かる前にイシューをオープンしましょう。受け入れられないかもしれない仕事に取り掛かる前に、暫くの間そのプロジェクトをウォッチし（ GitHub では、 ["Watch" をクリックすることで](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) 全ての会話の通知を受け取ることができます)、コミュニティメンバーを知ることは役に立つでしょう。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -468,7 +468,7 @@ master ブランチのコミットアクティビティをみてみましょう
 
 そのプロジェクトが GitHub 上にあるのであれば、下記がプルリクエストを提出する方法です：
 
-* **[リポジトリをフォークし](https://guides.github.com/activities/forking/)** ローカルにクローンしましょう。あなたのローカルと元の "upstream" リポジトリを remote として追加することで紐づけましょう。 "upstream" からの変更を頻繁にプルすることで、プルリクエストを提出する時にマージコンフリクトが起きづらくなるように、最新に追いついているようにしましょう。（より詳細な手順は[こちら](https://help.github.com/articles/syncing-a-fork/)を確認して下さい)。
+* **[リポジトリをフォークし](https://guides.github.com/activities/forking/)** ローカルにクローンしましょう。あなたのローカルと元の "upstream" リポジトリを remote として追加することで紐づけましょう。 "upstream" からの変更を頻繁にプルすることで、プルリクエストを提出する時にマージコンフリクトが起きづらくなるように、最新に追いついているようにしましょう。（より詳細な手順は[こちら](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork)を確認して下さい)。
 * あなたの変更のための**[ブランチを切りましょう](https://guides.github.com/introduction/flow/)**。
 * プルリクエストの中で**あらゆる関連するイシュー** や関連するドキュメントを参照しましょう （例えば、 "Closes #37." のように)。
 * もしあなたが HTML/CSS を変更するのであれば、**前後のスクリーンショットを含めましょう**。あなたのプルリクエストの本文に画像をドラッグアンドドロップしましょう。
diff --git a/_articles/ja/leadership-and-governance.md b/_articles/ja/leadership-and-governance.md
index 630ee1eb0c4..09df05fd359 100644
--- a/_articles/ja/leadership-and-governance.md
+++ b/_articles/ja/leadership-and-governance.md
@@ -73,7 +73,7 @@ related:
 
 [Vossibility](https://github.com/icecrime/vossibility-stack) のようなツールは、プロジェクトに対するコントリビュートを誰がやっているのか（やっていないのか）を公にトラッキングするのに役立ちます。こういった情報をドキュメント化することで、メンテナーは非公開の場で意思決定を行う派閥を作っているとコミュニティから認識されることを避けることができます。
 
-最後に、プロジェクトが GitHub 上にあるのであれば、プロジェクトを個人アカウントから Organization に移し、少なくとも一人の管理者をバックアップとして追加することを検討しましょう。 [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) を使うことで、権限や複数のリポジトリを管理し、[所有権を共有することで](../building-community/#プロジェクトの所有権を共有しよう)プロジェクトの資産を守ることがやりやすくなります。
+最後に、プロジェクトが GitHub 上にあるのであれば、プロジェクトを個人アカウントから Organization に移し、少なくとも一人の管理者をバックアップとして追加することを検討しましょう。 [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) を使うことで、権限や複数のリポジトリを管理し、[所有権を共有することで](../building-community/#プロジェクトの所有権を共有しよう)プロジェクトの資産を守ることがやりやすくなります。
 
 ## いつ他の人にコミット権限を与えるべきだろうか？
 
@@ -81,7 +81,7 @@ related:
 
 その一方で、大きく複雑なプロジェクトでは、プロジェクトに対して熱心に献身している人のみにコミット権限を与えたいと思うかもしれません。唯一の正解はありません - あなたが最も良いと思うことをやりましょう。
 
-もしプロジェクトが GitHub 上にあるのであれば、 [protected branches](https://help.github.com/articles/about-protected-branches/) を使うことで、どういった状況で誰が特定のブランチに push できるのかを管理することができます。
+もしプロジェクトが GitHub 上にあるのであれば、 [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) を使うことで、どういった状況で誰が特定のブランチに push できるのかを管理することができます。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 6ed9b3437b6..96abc58cbd1 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -28,7 +28,7 @@ related:
 
 ## パブリックな GitHub プロジェクトはオープンソースですか？
 
-GitHub 上で[新しいプロジェクトを作る](https://help.github.com/articles/creating-a-new-repository/)際、リポジトリをパブリックにするかプライベートにするか、2 つの選択肢があります。
+GitHub 上で[新しいプロジェクトを作る](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)際、リポジトリをパブリックにするかプライベートにするか、2 つの選択肢があります。
 
 ![リポジトリの作成](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ GitHub 上で[新しいプロジェクトを作る](https://help.github.com/arti
 
 [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/)。
+GitHub で新しいプロジェクトを作るときには、[ライセンスを追加するよう聞かれます](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository)。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 ## 私のプロジェクトでは追加のコントリビューターアグリーメントが必要でしょうか？
 
-おそらく必要ありません。大部分のオープンソースプロジェクトでは、オープンソースライセンスはインバウンド（コントリビューターから）もアウトバウンド（他のコントリビューターやユーザー向け）の両方のライセンスとして使うことができます。もしプロジェクトを GitHub 上においているのであれば、 GitHub の利用規約によってインバウンドとアウトバウンドが同じであるということがデフォルトとして[明記されています](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license)。
+おそらく必要ありません。大部分のオープンソースプロジェクトでは、オープンソースライセンスはインバウンド（コントリビューターから）もアウトバウンド（他のコントリビューターやユーザー向け）の両方のライセンスとして使うことができます。もしプロジェクトを GitHub 上においているのであれば、 GitHub の利用規約によってインバウンドとアウトバウンドが同じであるということがデフォルトとして[明記されています](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license)。
 
 追加のコントリビューターアグリーメントはしばしば Contributor License Agreement (CLA) と呼ばれます。これを作ることで、プロジェクトのメンテナーは運用上の手間が必要になってきます。どのくらいの手間がかかるかはプロジェクトとやり方によります。簡単な同意であれば、コントリビューターに対してプロジェクトのオープンソースライセンスに従ってコントリビュートする権利があるとクリックひとつで同意できる様になるでしょう。より複雑な同意になると、法務のレビューとコントリビューターの雇用主の署名が必要になるかもしれません。
 
diff --git a/_articles/ja/metrics.md b/_articles/ja/metrics.md
index 756ff67548c..2140e310f22 100644
--- a/_articles/ja/metrics.md
+++ b/_articles/ja/metrics.md
@@ -37,7 +37,7 @@ related:
 
 ![トラフィックグラフ](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-もしプロジェクトを GitHub 上にホストしているのであれば、何人があなたのプロジェクトを訪れていて、どこから来たのかを[見ることが出来ます](https://help.github.com/articles/about-repository-graphs/#traffic)。プロジェクトのページで、 "Insights" をクリックし、 "Traffic" をクリックします。このページでは、下記を見ることが出来ます:
+もしプロジェクトを GitHub 上にホストしているのであれば、何人があなたのプロジェクトを訪れていて、どこから来たのかを[見ることが出来ます](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository)。プロジェクトのページで、 "Insights" をクリックし、 "Traffic" をクリックします。このページでは、下記を見ることが出来ます:
 
 * **トータルページビュー:** プロジェクトが何回閲覧されたか
 
@@ -47,7 +47,7 @@ related:
 
 * **人気のあるコンテンツ:** 訪問者がプロジェクト上のどこを閲覧しているか。ページビューとユニークビジターをコンテンツごとに把握することが出来ます。
 
-[GitHub のスター](https://help.github.com/articles/about-stars/)も、プロジェクトの人気を測る上での基準となります。 GitHub のスターは必ずしもプロジェクトのダウンロード数や利用数と関連していませんが、何人がプロジェクトの通知を受け取っているかを知ることが出来ます。
+[GitHub のスター](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars)も、プロジェクトの人気を測る上での基準となります。 GitHub のスターは必ずしもプロジェクトのダウンロード数や利用数と関連していませんが、何人がプロジェクトの通知を受け取っているかを知ることが出来ます。
 
 また、[特定の場所での見つけやすさ](https://opensource.com/business/16/6/pirate-metrics)もトラッキングしたいかもしれません：例えば、 Google PageRank 、プロジェクトのウェブサイトからの流入や他のオープンソースプロジェクトやウェブサイトからの流入などです。
 
diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index 6eca1de6a5e..ed83b7fce28 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -106,9 +106,9 @@ _フリーソフトウェア_ という言葉も _オープンソース_ と同
 
 あなたのプロジェクトをオープンソースにするのがどの段階であれ、全てのプロジェクトは下記のドキュメントを含んでいるべきです：
 
-* [オープンソースライセンス](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)
-* [コントリビュートのガイドライン](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [オープンソースライセンス](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [コントリビュートのガイドライン](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [行動規範](../code-of-conduct/)
 
 メンテナーとして、これらの要素は期待値をコミュニケーションし、コントリビュートをマネジメントし、すべての人（あなた自身も含む）の法的権利を守る助けになります。これらによってあなたが良い経験を積むことができる可能性を大幅に増やします。
@@ -182,7 +182,7 @@ CONTRIBUTING ファイルはあなたのプロジェクトにどうやって参
 
 CONTRIBUTING ファイルを書くときに更に役に立つものとして、 @nayafia の [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) や @mozilla の ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) も参考になるでしょう。
 
-README に CONTRIBUTING ファイルへのリンクをすることで、より多くの人の目に触れるようになります。 [CONTRIBUTING ファイルをプロジェクトのリポジトリに置くことで](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)、 GitHub でコントリビューターがイシューを登録したり、プルリクエストをオープンする際に、そのファイルへのリンクが自動的に表示されます。
+README に CONTRIBUTING ファイルへのリンクをすることで、より多くの人の目に触れるようになります。 [CONTRIBUTING ファイルをプロジェクトのリポジトリに置くことで](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)、 GitHub でコントリビューターがイシューを登録したり、プルリクエストをオープンする際に、そのファイルへのリンクが自動的に表示されます。
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -256,7 +256,7 @@ README に CONTRIBUTING ファイルへのリンクをすることで、より
 ## 立ち上げ前のチェックリスト
 
 あなたのプロジェクトをオープンソースにする準備が整いましたか？ここにあなたの助けとなるよう、チェックリストを用意しました。全てにチェックが付きましたか？そうであれば準備万端です！
-["publish" をクリックして](https://help.github.com/articles/making-a-private-repository-public/)、自分を褒めてあげましょう。
+["publish" をクリックして](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility)、自分を褒めてあげましょう。
 
 **ドキュメント**
 
diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md
index 26a6bb5407e..75c2c7b92f5 100644
--- a/_articles/ko/best-practices.md
+++ b/_articles/ko/best-practices.md
@@ -213,7 +213,7 @@ related:
 
 테스트는 기여자가 아무것도 망가트리지 않았다는 확신을 가질 수 있게 해줍니다. 여러분이 기여를 더 빨리 검토하고 적용하기에도 좋습니다. 여러분이 더 적극적으로 반응한다면 커뮤니티의 모두도 더 적극적으로 참여할 것입니다.
 
-들어오는 기여를 대상으로 자동으로 수행되는 테스트를 작성하고, 기여자들이 테스트를 로컬에서도 쉽게 수행할 수 있게 구성하세요. 모든 코드 기여는 제출되기 전에 테스트를 통과하도록 하세요. 모든 제출물에 대해 최소한의 수준을 확보할 수 있을 것입니다. GitHub의 [Required status checks](https://help.github.com/articles/about-required-status-checks/) 기능은 어떤 커밋도 테스트를 통과하지 않고서는 병합되지 않도록 도와줍니다.
+들어오는 기여를 대상으로 자동으로 수행되는 테스트를 작성하고, 기여자들이 테스트를 로컬에서도 쉽게 수행할 수 있게 구성하세요. 모든 코드 기여는 제출되기 전에 테스트를 통과하도록 하세요. 모든 제출물에 대해 최소한의 수준을 확보할 수 있을 것입니다. GitHub의 [Required status checks](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) 기능은 어떤 커밋도 테스트를 통과하지 않고서는 병합되지 않도록 도와줍니다.
 
 테스트를 추가할 때는 반드시 CONTRIBUTING 파일에 어떻게 테스트가 동작하는지 설명하세요.
 
diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md
index 307442652bb..a59c1f58883 100644
--- a/_articles/ko/building-community.md
+++ b/_articles/ko/building-community.md
@@ -167,7 +167,7 @@ CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명
 
 * **모든 참여자에게 커밋 권한을 부여하세요.** @felixge는 이 방법이 사람들이 [더 열심히 패치를 개선하게 한다는 사실](http://felixge.de/2013/03/11/the-pull-request-hack.html)을 알았고, 그가 자리에 없는 동안 프로젝트 관리자 일을 맡아 주는 사람들을 발견하기도 했습니다.
 
-* 여러분의 프로젝트가 GitHub에서 진행되고 있다면 **프로젝트를 개인 계정에서 [조직 계정](https://help.github.com/articles/creating-a-new-organization-account/)으로 옮기고** 예비 관리자를 등록하세요. 조직 계정을 활용하면 외부의 협력자들과 함께 일하기 더 쉽습니다.
+* 여러분의 프로젝트가 GitHub에서 진행되고 있다면 **프로젝트를 개인 계정에서 [조직 계정](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)으로 옮기고** 예비 관리자를 등록하세요. 조직 계정을 활용하면 외부의 협력자들과 함께 일하기 더 쉽습니다.
 
 현실에서 [대부분의 프로젝트](https://peerj.com/preprints/1233/)는 한두 명의 관리자가 거의 모든 일을 담당합니다. 여러분의 프로젝트와 커뮤니티가 성장할수록 위 방법이 도움을 구하기 좋습니다.
 
diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index d4bea3994f4..9af217e5648 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -435,7 +435,7 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또
 
 이슈나 PR을 열기 전에 프로젝트의 기여 문서(일반적으로 CONTRIBUTING 또는 README 파일)에서 뭔가 구체적인 내용을 포함해야 하는지 확인하세요. 프로젝트에서 여러분에게 특정 템플릿을 따르거나 테스트를 사용하도록 요구할 수 있습니다.
 
-실질적인 기여를 하고 싶다면, 작업하기 전에 이슈를 열고 물어보세요. 승인되지 않을 수도 있는 작업을 하기 전에(깃허브에서는, ["Watch"를 클릭](https://help.github.com/articles/watching-repositories/)해서 토론을 알림 받을 수 있습니다), 커뮤니티 구성원들을 알게 되면 도움이 됩니다.
+실질적인 기여를 하고 싶다면, 작업하기 전에 이슈를 열고 물어보세요. 승인되지 않을 수도 있는 작업을 하기 전에(깃허브에서는, ["Watch"를 클릭](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications)해서 토론을 알림 받을 수 있습니다), 커뮤니티 구성원들을 알게 되면 도움이 됩니다.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -470,7 +470,7 @@ PR이 반드시 완료된 작업을 포함할 필요는 없습니다. 보통 다
 
 프로젝트가 GitHub에 있는 경우 PR을 제출하는 방법은 다음과 같습니다.
 
-* **[저장소를 포크](https://guides.github.com/activities/forking/)**하고 로컬에 복제(Clone)합니다. 리모트로 추가하여 로컬을 원래의 "업스트림" 저장소에 연결하세요. PR을 제출할 때 충돌이 발생할 가능성을 낮추기 위해 "업스트림"의 변경 사항을 자주 가져 와서 최신 상태로 유지하세요. (자세한 내용은 [여기](https://help.github.com/articles/syncing-a-fork/)를 참조하세요.)
+* **[저장소를 포크](https://guides.github.com/activities/forking/)**하고 로컬에 복제(Clone)합니다. 리모트로 추가하여 로컬을 원래의 "업스트림" 저장소에 연결하세요. PR을 제출할 때 충돌이 발생할 가능성을 낮추기 위해 "업스트림"의 변경 사항을 자주 가져 와서 최신 상태로 유지하세요. (자세한 내용은 [여기](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork)를 참조하세요.)
 * 수정을 위한 **[브랜치를 생성](https://guides.github.com/introduction/flow/)**하세요.
 * **모든 관련 이슈** 혹은 지원 문서를 참조하세요. (ex. "Closes #37.")
 * 변경 사항에 HTML/CSS가 포함되어 있는 경우 **적용 전/후 스크린샷을 첨부**하세요. PR의 본문에 이미지를 끌어다 놓으면 됩니다.
diff --git a/_articles/ko/leadership-and-governance.md b/_articles/ko/leadership-and-governance.md
index c116dff5055..3cc76c8aedf 100644
--- a/_articles/ko/leadership-and-governance.md
+++ b/_articles/ko/leadership-and-governance.md
@@ -73,7 +73,7 @@ related:
 
 누가 프로젝트에 기여하고 누가 그렇지 않은지 공개적으로 파악하는 데 [Vossibility](https://github.com/icecrime/vossibility-stack) 같은 툴이 도움을 줍니다. 이런 정보를 문서화하면 관리자들이 불공평한 결정을 내린다는 인식을 피할 수 있습니다.
 
-마지막으로, 여러분의 프로젝트가 GitHub에서 진행되고 있다면 프로젝트를 여러분의 개인 계정에서 조직 계정으로 이동하는 것을 고려해 보세요. [조직 계정](https://help.github.com/articles/creating-a-new-organization-account/) 기능이 여러 저장소의 권한 관리, [공동 소유](../building-community/#프로젝트를-공동으로-소유하세요)를 통한 프로젝트 정책 보호를 쉽게 만들어 줍니다.
+마지막으로, 여러분의 프로젝트가 GitHub에서 진행되고 있다면 프로젝트를 여러분의 개인 계정에서 조직 계정으로 이동하는 것을 고려해 보세요. [조직 계정](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) 기능이 여러 저장소의 권한 관리, [공동 소유](../building-community/#프로젝트를-공동으로-소유하세요)를 통한 프로젝트 정책 보호를 쉽게 만들어 줍니다.
 
 ## 커밋 권한은 언제 부여해야 하나요?
 
@@ -81,7 +81,7 @@ related:
 
 반면, 특히 크고 복잡한 프로젝트에서는 노력을 보인 사람들에게만 커밋 권한을 부여할 수도 있습니다. 정해진 방법은 없습니다. 가장 편한 방법을 선택하세요!
 
-여러분의 프로젝트가 GitHub에서 진행되고 있다면 [보호 브랜치](https://help.github.com/articles/about-protected-branches/) 기능을 사용해 누가 어떠한 상황에 특정 브랜치에 푸시할 수 있는지 지정할 수 있습니다.
+여러분의 프로젝트가 GitHub에서 진행되고 있다면 [보호 브랜치](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) 기능을 사용해 누가 어떠한 상황에 특정 브랜치에 푸시할 수 있는지 지정할 수 있습니다.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index d71c2a84193..e3924006b0f 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -28,7 +28,7 @@ related:
 
 ## 깃허브의 공개 프로젝트는 오픈소스인가요?
 
-깃허브에서 [새로운 프로젝트를 만들려고](https://help.github.com/articles/creating-a-new-repository/) 할 때, **비공개** 또는 **공개** 저장소로 만드는 옵션을 선택할 수 있습니다.
+깃허브에서 [새로운 프로젝트를 만들려고](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) 할 때, **비공개** 또는 **공개** 저장소로 만드는 옵션을 선택할 수 있습니다.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ related:
 
 [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/).
+GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 것인지 물어봅니다](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
 
 ## 내 프로젝트에 추가 기여자 계약이 필요한가요?
 
-아마도 그렇지 않습니다. 대다수의 오픈소스 프로젝트에서 공개 소스 라이선스는 인바운드(기여자)와 아웃바운드(다른 참여자 및 사용자) 라이선스로 암묵적으로 사용됩니다. 프로젝트가 GitHub에 있는 경우, GitHub 서비스 약관은 "인바운드 = 아웃 바운드" [명시적 기본값](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license)으로 지정합니다.
+아마도 그렇지 않습니다. 대다수의 오픈소스 프로젝트에서 공개 소스 라이선스는 인바운드(기여자)와 아웃바운드(다른 참여자 및 사용자) 라이선스로 암묵적으로 사용됩니다. 프로젝트가 GitHub에 있는 경우, GitHub 서비스 약관은 "인바운드 = 아웃 바운드" [명시적 기본값](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license)으로 지정합니다.
 
 기여자 라이선스 계약(CLA)이라고도 부르는 추가 기여자 계약은 프로젝트 메인테이너를 위한 관리 작업을 생성할 수 있습니다. 계약서에 얼마나 많은 작업을 추가할지는 프로젝트와 구현에 달려 있습니다. 간단한 동의는 프로젝트 참여자가 프로젝트 오픈소스 라이선스 하에 기여할 수 있는 권리를 클릭으로 확인해야 할 수도 있습니다. 보다 복잡한 합의는 법적 검토와 기여자 고용주의 서명을 요구할 수 있습니다.
 
diff --git a/_articles/ko/metrics.md b/_articles/ko/metrics.md
index e32172b03f9..e5e3e502558 100644
--- a/_articles/ko/metrics.md
+++ b/_articles/ko/metrics.md
@@ -47,7 +47,7 @@ If you _are_ interested in understanding your project on a deeper level, read on
 
 * **인기 콘텐츠:** 방문자가 프로젝트에서 어디로 이동했는지 알려주며, 페이지 뷰와 고유 방문자별로 세분화됩니다.
 
-[GitHub stars](https://help.github.com/articles/about-stars/)는 또한 인기의 기준치 측정을 제공하는 데 도움이 될 수 있습니다. GitHub star는 반드시 다운로드 및 사용량과 상관관계가 있는 것은 아니지만, 얼마나 많은 사람들이 귀하의 작업에 주의를 기울이고 있는지 말해 줄 수 있습니다.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars)는 또한 인기의 기준치 측정을 제공하는 데 도움이 될 수 있습니다. GitHub star는 반드시 다운로드 및 사용량과 상관관계가 있는 것은 아니지만, 얼마나 많은 사람들이 귀하의 작업에 주의를 기울이고 있는지 말해 줄 수 있습니다.
 
 [특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함할 수 있습니다.
 
diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md
index f0f6b5f3fee..33a2f474b29 100644
--- a/_articles/ko/starting-a-project.md
+++ b/_articles/ko/starting-a-project.md
@@ -113,9 +113,9 @@ related:
 
 프로젝트를 오픈소스화하기로 결정한 시점에 상관없이 모든 프로젝트에는 다음과 같은 문서가 포함되어 있어야 합니다.
 
-* [오픈소스 라이선스](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)
-* [기여 가이드라인](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [오픈소스 라이선스](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [기여 가이드라인](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [행동 강령](../code-of-conduct/)
 
 관리자는 이러한 구성 요소로 기대치를 전달하고, 기여를 관리하고, (여러분을 포함한) 모두의 법적 권리를 보호할 수 있습니다. 위 문서들은 여러분이 긍정적인 경험을 하게 될 가능성을 크게 증가시킵니다.
@@ -189,7 +189,7 @@ CONTRIBUTING 파일은 잠재 기여자들에게 프로젝트에 기여하는 
 
 CONTRIBUTING 파일을 작성하는 데 도움이 필요하면 @nayafia의 [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) 또는 @mozilla의 ["How to Build a CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/contributing/)을 참조하세요.
 
-README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할 수 있습니다. [CONTRIBUTING 파일을 프로젝트의 저장소에 두면](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) 기여자가 이슈를 생성하거나 PR를 열 때 GitHub가 자동으로 링크를 생성합니다.
+README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할 수 있습니다. [CONTRIBUTING 파일을 프로젝트의 저장소에 두면](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors) 기여자가 이슈를 생성하거나 PR를 열 때 GitHub가 자동으로 링크를 생성합니다.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -262,7 +262,7 @@ README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할
 
 ## 오픈소스 준비 체크리스트
 
-프로젝트를 오픈소스화할 준비가 되셨습니까? 다음은 도움이 되는 체크리스트입니다. 모든 칸에 체크하셨나요? 이제 출발할 준비가 되었습니다! ["공개"를 클릭](https://help.github.com/articles/making-a-private-repository-public/)하고 등을 토닥이세요.
+프로젝트를 오픈소스화할 준비가 되셨습니까? 다음은 도움이 되는 체크리스트입니다. 모든 칸에 체크하셨나요? 이제 출발할 준비가 되었습니다! ["공개"를 클릭](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility)하고 등을 토닥이세요.
 
 **문서**
 
diff --git a/_articles/leadership-and-governance.md b/_articles/leadership-and-governance.md
index 0274e9a99c2..2b64e99a7ab 100644
--- a/_articles/leadership-and-governance.md
+++ b/_articles/leadership-and-governance.md
@@ -73,7 +73,7 @@ Once you've established leadership roles, don't forget to document how people ca
 
 Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately.
 
-Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project).
+Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project).
 
 ## When should I give someone commit access?
 
@@ -81,7 +81,7 @@ Some people think you should give commit access to everybody who makes a contrib
 
 On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable!
 
-If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances.
+If your project is on GitHub, you can use [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) to manage who can push to a particular branch, and under which circumstances.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/legal.md b/_articles/legal.md
index 579b54a19cb..d86e8f800dd 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -28,7 +28,7 @@ Finally, your project may have dependencies with license requirements that you w
 
 ## Are public GitHub projects open source?
 
-When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**.
+When you [create a new project](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) on GitHub, you have the option to make the repository **private** or **public**.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ You're in luck, because today, open source licenses are standardized and easy to
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
 
-When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+When you create a new project on GitHub, you'll be [asked to add a license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -93,7 +93,7 @@ Alternatively, you can have contributors pre-approve certain license changes via
 
 ## Does my project need an additional contributor agreement?
 
-Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers.
 
diff --git a/_articles/metrics.md b/_articles/metrics.md
index 145dd18119b..06cf2741672 100644
--- a/_articles/metrics.md
+++ b/_articles/metrics.md
@@ -37,7 +37,7 @@ Before anybody can use or contribute back to your project, they need to know it
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see:
+If your project is hosted on GitHub, [you can view](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see:
 
 * **Total page views:** Tells you how many times your project was viewed
 
@@ -47,7 +47,7 @@ If your project is hosted on GitHub, [you can view](https://help.github.com/arti
 
 * **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
 
 You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites.
 
diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index fc11cd94e4d..d5db33cff65 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -165,7 +165,7 @@ Anda tidak perlu melakukan semuanya sendiri. Komuniti projek anda wujud dengan a
 
 Sekiranya anda sedang mencari orang lain, mulakan dengan bertanya-tanya
 
-Salah satu cara untuk mendapatkan penyumbang baru adalah dengan secara eksplisit [melabelkan masalah yang cukup mudah untuk ditangani oleh pemula](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub kemudian akan mengemukakan permasalahan ini di pelbagai tempat di platform, sehingga meningkatkan keterlihatannya.
+Salah satu cara untuk mendapatkan penyumbang baru adalah dengan secara eksplisit [melabelkan masalah yang cukup mudah untuk ditangani oleh pemula](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub kemudian akan mengemukakan permasalahan ini di pelbagai tempat di platform, sehingga meningkatkan keterlihatannya.
 
 Apabila anda melihat penyumbang baru memberikan sumbangan berulang, kenali karya mereka dengan menawarkan lebih banyak tanggungjawab. Mendokumentasikan bagaimana orang lain dapat berkembang menjadi peranan kepemimpinan jika mereka mahu.
 
@@ -215,7 +215,7 @@ Salah satu cara terpenting untuk mengautomasikan projek anda adalah dengan menam
 
 Ujian membantu penyumbang merasa yakin bahawa mereka tidak akan merosakkan apa-apa. Mereka juga memudahkan anda menyemak dan menerima sumbangan dengan cepat. Semakin responsif anda, semakin aktif komuniti anda.
 
-Sediakan ujian automatik yang akan dijalankan pada semua sumbangan yang masuk, dan pastikan ujian anda dapat dijalankan dengan mudah secara tempatan oleh penyumbang. Wajibkan semua sumbangan kod lulus ujian anda sebelum dapat dihantar. Anda akan membantu menetapkan standard kualiti minimum untuk semua penyerahan. [Pemeriksaan status yang diperlukan] (<https://help.github.com/articles/about-required-status-checks/>) di GitHub dapat membantu memastikan tiada perubahan digabungkan tanpa ujian anda lulus.
+Sediakan ujian automatik yang akan dijalankan pada semua sumbangan yang masuk, dan pastikan ujian anda dapat dijalankan dengan mudah secara tempatan oleh penyumbang. Wajibkan semua sumbangan kod lulus ujian anda sebelum dapat dihantar. Anda akan membantu menetapkan standard kualiti minimum untuk semua penyerahan. [Pemeriksaan status yang diperlukan] (<https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging>) di GitHub dapat membantu memastikan tiada perubahan digabungkan tanpa ujian anda lulus.
 
 Sekiranya anda menambahkan ujian, pastikan untuk menerangkan bagaimana ia berfungsi dalam fail CONTRIBUTING anda.
 
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index 4226e9d79a7..b589f972ae8 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -28,7 +28,7 @@ Mulakan dengan dokumentasi anda:
 
 * **Permudahkan seseorang untuk menggunakan projek anda.**[README yang mesra](../starting-a-project/#menulis-readme) dan contoh kod yang jelas akan memudahkan sesiapa sahaja yang memasuki projek anda untuk memulakan.
 * **Terangkan dengan jelas cara menyumbang**, menggunakan [fail CONTRIBUTING anda](../starting-a-project/#menulis-garis-panduan-penyumbang-anda) dan mengemas kini masalah anda.
-* **Isu pertama yang baik**: Untuk membantu penyumbang baru memulakan, pertimbangkan secara jelas [masalah pelabelan yang cukup mudah untuk diatasi oleh pemula](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub kemudian akan memaparkan isu-isu ini di berbagai tempat di platform, meningkatkan sumbangan berguna, dan mengurangkan geseran dari pengguna menangani masalah yang terlalu sukar untuk tahap mereka.
+* **Isu pertama yang baik**: Untuk membantu penyumbang baru memulakan, pertimbangkan secara jelas [masalah pelabelan yang cukup mudah untuk diatasi oleh pemula](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub kemudian akan memaparkan isu-isu ini di berbagai tempat di platform, meningkatkan sumbangan berguna, dan mengurangkan geseran dari pengguna menangani masalah yang terlalu sukar untuk tahap mereka.
 
 [GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) menunjukkan dokumentasi yang tidak lengkap atau membingungkan adalah masalah terbesar bagi pengguna sumber terbuka. Dokumentasi yang baik mengundang orang untuk berinteraksi dengan projek anda. Akhirnya, seseorang akan membuka masalah atau menarik permintaan. Gunakan interaksi ini sebagai peluang untuk mengalihkannya ke corong.
 
@@ -167,7 +167,7 @@ Lihat apakah anda boleh mencari cara untuk berkongsi pemilikan dengan komuniti a
 
 * **Berikan akses kepada setiap penyumbang.** @felixge mendapati bahawa ini menjadikan orang [lebih teruja untuk menggilap patch mereka](https://felixge.de/2013/03/11/the-pull-request-hack.html), dan dia malah menjumpai penyelenggara baru untuk projek-projek yang belum pernah dia kerjakan sebentar lagi.
 
-* Sekiranya projek anda berada di GitHub, **pindahkan projek anda dari akaun peribadi anda ke [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** dan tambahkan sekurang-kurangnya satu pentadbir sandaran. Organisasi menjadikannya lebih mudah untuk mengerjakan projek dengan kolaborator luar.
+* Sekiranya projek anda berada di GitHub, **pindahkan projek anda dari akaun peribadi anda ke [Organization](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** dan tambahkan sekurang-kurangnya satu pentadbir sandaran. Organisasi menjadikannya lebih mudah untuk mengerjakan projek dengan kolaborator luar.
 
 Kenyataannya adalah bahawa[most projects only have](https://peerj.com/preprints/1233/)satu atau dua penyelenggara yang melakukan sebahagian besar kerja. Semakin besar projek anda, dan semakin besar komuniti anda, semakin mudah mendapatkan bantuan.
 
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index 29025693fee..472cd114d53 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -439,7 +439,7 @@ Sekiranya anda tidak menemui idea anda di tempat lain, anda sudah bersedia untuk
 
 Sebelum anda membuka masalah atau menarik permintaan, periksa dokumen penyumbang projek (biasanya fail yang disebut CONTRIBUTING, atau di README), untuk melihat sama ada anda perlu memasukkan sesuatu yang spesifik. Contohnya, mereka mungkin meminta anda mengikuti templat, atau menghendaki anda menggunakan ujian.
 
-Sekiranya anda ingin memberikan sumbangan yang besar, buka isu yang perlu ditanyakan sebelum mengusahakannya. Sangat berguna untuk menonton projek sebentar (di GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) untuk diberitahu tentang semua perbualan), dan berkenalan dengan anggota masyarakat, sebelum melakukan pekerjaan yang mungkin tidak diterima.
+Sekiranya anda ingin memberikan sumbangan yang besar, buka isu yang perlu ditanyakan sebelum mengusahakannya. Sangat berguna untuk menonton projek sebentar (di GitHub, [you can click "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) untuk diberitahu tentang semua perbualan), dan berkenalan dengan anggota masyarakat, sebelum melakukan pekerjaan yang mungkin tidak diterima.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -474,7 +474,7 @@ Permintaan tarikan tidak harus mewakili kerja yang telah siap. Biasanya lebih ba
 
 Sekiranya projek tersebut berada di GitHub, berikut adalah cara mengemukakan permintaan tarik:
 
-* **[Fork the repository](https://guides.github.com/activities/forking/)** dan mengklonnya secara tempatan. Sambungkan tempatan anda ke repositori "hulu" yang asal dengan menambahkannya sebagai alat kawalan jauh. Tarik perubahan dari "hulu" secara berkala sehingga Anda terus mengetahui sehingga ketika anda mengajukan permintaan penarikan, konflik penggabungan cenderung tidak terjadi.(Lihat arahan yang lebih terperinci [here](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork the repository](https://guides.github.com/activities/forking/)** dan mengklonnya secara tempatan. Sambungkan tempatan anda ke repositori "hulu" yang asal dengan menambahkannya sebagai alat kawalan jauh. Tarik perubahan dari "hulu" secara berkala sehingga Anda terus mengetahui sehingga ketika anda mengajukan permintaan penarikan, konflik penggabungan cenderung tidak terjadi.(Lihat arahan yang lebih terperinci [here](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Create a branch](https://guides.github.com/introduction/flow/)** untuk pengeditan anda.
 * **Rujuk masalah yang berkaitan** atau dokumentasi sokongan dalam PR anda (misalnya, "Tutup # 37.")
 * **Sertakan tangkapan skrin sebelum dan sesudah** jika perubahan anda merangkumi perbezaan dalam HTML / CSS. Seret dan lepaskan gambar ke badan permintaan tarikan anda.
diff --git a/_articles/ms/leadership-and-governance.md b/_articles/ms/leadership-and-governance.md
index 7fea23d4e85..9dee654e49c 100644
--- a/_articles/ms/leadership-and-governance.md
+++ b/_articles/ms/leadership-and-governance.md
@@ -73,7 +73,7 @@ Setelah anda menentukan peranan kepemimpinan, jangan lupa untuk mendokumentasika
 
 Alatan seperti [Vossibility](https://github.com/icecrime/vossibility-stack) dapat membantu anda mengesan secara terbuka siapa (atau tidak) yang menyumbang kepada projek tersebut. Mendokumentasikan maklumat ini mengelakkan persepsi masyarakat bahawa penyelenggara adalah klise yang membuat keputusannya secara tertutup.
 
-Akhirnya, jika projek anda berada di GitHub, pertimbangkan untuk memindahkan projek anda dari akaun peribadi anda ke Organisasi dan tambahkan sekurang-kurangnya satu pentadbir sandaran. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/)mempermudah untuk menguruskan kebenaran dan beberapa repositori dan melindungi warisan projek anda melalui [pemilikan bersama](../building-community/#kongsi-pemilikan-projek-anda).
+Akhirnya, jika projek anda berada di GitHub, pertimbangkan untuk memindahkan projek anda dari akaun peribadi anda ke Organisasi dan tambahkan sekurang-kurangnya satu pentadbir sandaran. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)mempermudah untuk menguruskan kebenaran dan beberapa repositori dan melindungi warisan projek anda melalui [pemilikan bersama](../building-community/#kongsi-pemilikan-projek-anda).
 
 ## Bilakah saya harus memberikan akses kepada seseorang?
 
@@ -81,7 +81,7 @@ Sebilangan orang berpendapat bahawa anda harus memberikan akses kepada semua ora
 
 Sebaliknya, terutamanya untuk projek yang lebih besar dan lebih kompleks, anda mungkin hanya ingin memberikan akses kepada orang yang telah menunjukkan komitmen mereka. Tidak ada cara yang betul untuk melakukannya - lakukan perkara yang membuat anda paling selesa!
 
-Sekiranya projek anda berada di GitHub, anda boleh menggunakannya [protected branches](https://help.github.com/articles/about-protected-branches/) untuk menguruskan siapa yang boleh mendorong ke cabang tertentu, dan dalam keadaan apa.
+Sekiranya projek anda berada di GitHub, anda boleh menggunakannya [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) untuk menguruskan siapa yang boleh mendorong ke cabang tertentu, dan dalam keadaan apa.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index 630b41d0897..57998019f2f 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -28,7 +28,7 @@ Akhirnya, projek anda mungkin mempunyai kebergantungan dengan keperluan lesen ya
 
 ## Adakah projek GitHub awam terbuka?
 
-Bila kamu [create a new project](https://help.github.com/articles/creating-a-new-repository/) di GitHub, anda mempunyai pilihan untuk menjadikan repositori **peribadi** atau **awam**.
+Bila kamu [create a new project](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) di GitHub, anda mempunyai pilihan untuk menjadikan repositori **peribadi** atau **awam**.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Anda bernasib baik, kerana hari ini, lesen sumber terbuka diseragamkan dan mudah
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) adalah lesen sumber terbuka yang paling popular, tetapi ada pilihan lain untuk dipilih. Anda boleh mendapatkan teks lengkap lesen ini, dan arahan mengenai cara menggunakannya, di[choosealicense.com](https://choosealicense.com/).
 
-Apabila anda membuat projek baru di GitHub, anda akan menjadi [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+Apabila anda membuat projek baru di GitHub, anda akan menjadi [asked to add a license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ Sebagai alternatif, anda boleh meminta penyumbang bersetuju terlebih dahulu (mel
 
 ## Adakah projek saya memerlukan perjanjian penyumbang tambahan?
 
-Mungkin tidak. Untuk sebahagian besar projek sumber terbuka, lesen sumber terbuka secara implisit berfungsi sebagai lesen masuk (dari penyumbang) dan keluar (kepada penyumbang dan pengguna lain). Sekiranya projek anda berada di GitHub, Syarat Perkhidmatan GitHub menjadikan "inbound = outbound" sebagai [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Mungkin tidak. Untuk sebahagian besar projek sumber terbuka, lesen sumber terbuka secara implisit berfungsi sebagai lesen masuk (dari penyumbang) dan keluar (kepada penyumbang dan pengguna lain). Sekiranya projek anda berada di GitHub, Syarat Perkhidmatan GitHub menjadikan "inbound = outbound" sebagai [explicit default](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Perjanjian penyumbang tambahan - sering disebut Contributor License Agreement (CLA) - dapat membuat kerja pentadbiran untuk penyelenggara projek. Berapa banyak kerja yang ditambahkan oleh perjanjian bergantung pada projek dan pelaksanaannya. Perjanjian mudah mungkin memerlukan penyumbang mengesahkan, dengan satu klik, bahawa mereka mempunyai hak yang diperlukan untuk menyumbang di bawah lesen sumber terbuka projek. Perjanjian yang lebih rumit mungkin memerlukan semakan undang-undang dan pendaftaran dari majikan pencarum.
 
diff --git a/_articles/ms/metrics.md b/_articles/ms/metrics.md
index f7ea0bf3b22..b6e102b9951 100644
--- a/_articles/ms/metrics.md
+++ b/_articles/ms/metrics.md
@@ -37,7 +37,7 @@ Sebelum ada yang dapat menggunakan atau menyumbang kembali ke projek anda, merek
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Sekiranya projek anda dihoskan di GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) berapa ramai orang yang datang ke projek anda dan dari mana asalnya. Dari halaman projek anda, klik "Wawasan", kemudian "Lalu Lintas". Di halaman ini, anda dapat melihat:
+Sekiranya projek anda dihoskan di GitHub, [you can view](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) berapa ramai orang yang datang ke projek anda dan dari mana asalnya. Dari halaman projek anda, klik "Wawasan", kemudian "Lalu Lintas". Di halaman ini, anda dapat melihat:
 
 * **Jumlah paparan halaman:** Memberitahu anda berapa kali projek anda dilihat
 
@@ -47,7 +47,7 @@ Sekiranya projek anda dihoskan di GitHub, [you can view](https://help.github.com
 
 * **Kandungan popular:** Memberitahu anda tempat pelawat pergi ke projek anda, dipecah mengikut paparan halaman dan pelawat unik.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) juga dapat membantu memberikan ukuran populariti asas. Walaupun bintang GitHub tidak semestinya berkorelasi dengan muat turun dan penggunaan, mereka dapat memberitahu anda berapa banyak orang yang memperhatikan pekerjaan anda.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) juga dapat membantu memberikan ukuran populariti asas. Walaupun bintang GitHub tidak semestinya berkorelasi dengan muat turun dan penggunaan, mereka dapat memberitahu anda berapa banyak orang yang memperhatikan pekerjaan anda.
 
 Anda juga mungkin mahu [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): sebagai contoh, Google PageRank, lalu lintas rujukan dari laman web projek anda, atau rujukan dari projek atau laman web sumber terbuka yang lain.
 
diff --git a/_articles/ms/starting-a-project.md b/_articles/ms/starting-a-project.md
index e9aed52bf4f..7768928d622 100644
--- a/_articles/ms/starting-a-project.md
+++ b/_articles/ms/starting-a-project.md
@@ -106,9 +106,9 @@ Secara umum, anda harus membuka sumber projek anda apabila anda merasa selesa me
 
 Tidak kira tahap mana anda memutuskan untuk membuka sumber projek anda, setiap projek harus merangkumi dokumentasi berikut:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 Sebagai penyelenggara, komponen ini akan membantu anda menyampaikan harapan, menguruskan sumbangan, dan melindungi hak undang-undang setiap orang (termasuk milik anda). Mereka meningkatkan peluang anda untuk mendapat pengalaman positif.
@@ -182,7 +182,7 @@ Lama kelamaan, anda mungkin menambahkan soalan lain yang sering diajukan ke fail
 
 Untuk lebih banyak bantuan dalam menulis fail CONTRIBUTING anda, lihat@nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) atau @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Pautkan ke fail CONTRIBUTING anda dari README anda, sehingga lebih banyak orang melihatnya. Jika awak [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/),GitHub akan memaut ke fail anda secara automatik apabila penyumbang membuat masalah atau membuka permintaan tarik.
+Pautkan ke fail CONTRIBUTING anda dari README anda, sehingga lebih banyak orang melihatnya. Jika awak [place the CONTRIBUTING file in your project's repository](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors),GitHub akan memaut ke fail anda secara automatik apabila penyumbang membuat masalah atau membuka permintaan tarik.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ Anda tidak perlu menulis panduan gaya untuk projek anda semasa anda baru memulak
 
 ## Senarai semak pra-pelancaran anda
 
-Bersedia untuk membuka sumber projek anda? Berikut adalah senarai semak untuk membantu. Tandakan semua kotak? Anda sudah bersedia untuk pergi! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) dan tepuk punggung.
+Bersedia untuk membuka sumber projek anda? Berikut adalah senarai semak untuk membantu. Tandakan semua kotak? Anda sudah bersedia untuk pergi! [Click "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) dan tepuk punggung.
 
 **Dokumentasi**
 
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index 0fedcb43424..999a9fe71b1 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -174,7 +174,7 @@ U hoeft niet alles zelf te doen. De gemeenschap van uw project bestaat niet voor
 
 Als je op zoek bent naar anderen om bij te praten, begin dan met rond te vragen.
 
-Een manier om nieuwe bijdragers te werven, is door expliciet [label problemen die voor beginners eenvoudig genoeg zijn om aan te pakken](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub zal deze problemen vervolgens op verschillende plaatsen op het platform aan de oppervlakte brengen, waardoor hun zichtbaarheid wordt vergroot.
+Een manier om nieuwe bijdragers te werven, is door expliciet [label problemen die voor beginners eenvoudig genoeg zijn om aan te pakken](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub zal deze problemen vervolgens op verschillende plaatsen op het platform aan de oppervlakte brengen, waardoor hun zichtbaarheid wordt vergroot.
 
 Als je ziet dat nieuwe bijdragers herhaaldelijk bijdragen leveren, erken dan hun werk door meer verantwoordelijkheid te bieden. Documenteer hoe anderen kunnen uitgroeien tot leiderschapsrollen als ze dat willen.
 
@@ -228,7 +228,7 @@ Een van de belangrijkste manieren waarop u uw project kunt automatiseren, is doo
 
 Tests helpen bijdragers het vertrouwen te hebben dat ze niets zullen breken. Ze maken het ook gemakkelijker voor u om bijdragen snel te bekijken en te accepteren. Hoe responsiever u bent, hoe meer uw gemeenschap betrokken kan zijn.
 
-Stel automatische tests in die op alle inkomende bijdragen worden uitgevoerd en zorg ervoor dat uw tests gemakkelijk lokaal door bijdragers kunnen worden uitgevoerd. Vereisen dat alle codebijdragen slagen voor uw tests voordat ze kunnen worden ingediend. Je helpt mee met het instellen van een minimale kwaliteitsnorm voor alle inzendingen. [Vereiste statuschecks](https://help.github.com/articles/about-required-status-checks/) op GitHub kan ervoor zorgen dat geen enkele wijziging wordt gemerged zonder dat uw tests slagen.
+Stel automatische tests in die op alle inkomende bijdragen worden uitgevoerd en zorg ervoor dat uw tests gemakkelijk lokaal door bijdragers kunnen worden uitgevoerd. Vereisen dat alle codebijdragen slagen voor uw tests voordat ze kunnen worden ingediend. Je helpt mee met het instellen van een minimale kwaliteitsnorm voor alle inzendingen. [Vereiste statuschecks](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) op GitHub kan ervoor zorgen dat geen enkele wijziging wordt gemerged zonder dat uw tests slagen.
 
 Als u tests toevoegt, leg dan uit hoe ze werken in uw CONTRIBUTING-bestand.
 
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index 15b99b75b94..33a088bbbff 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -28,7 +28,7 @@ Begin met uw documentatie:
 
 * **Maak het voor iemand gemakkelijk om uw project te gebruiken.** [Een vriendelijke README](../starting-a-project/#een-readme-schrijven) en duidelijke codevoorbeelden maken het gemakkelijker voor iedereen die op uw project belandt om aan de slag te gaan.
 * **Leg duidelijk uit hoe u kunt bijdragen**, gebruik [je CONTRIBUTING-bestand](../starting-a-project/#schrijven-van-uw-bijdrage-richtlijnen) en uw issues up-to-date houden.
-* **Goede first issues**: Overweeg expliciet om nieuwe bijdragers op weg te helpen [label issues die eenvoudig genoeg zijn voor beginners om aan te pakken](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub zal deze issues vervolgens op verschillende plaatsen op het platform aan de oppervlakte brengen, waardoor nuttige bijdragen worden verhoogd en de wrijving wordt verminderd van gebruikers die problemen aanpakken die te moeilijk zijn voor hun niveau.
+* **Goede first issues**: Overweeg expliciet om nieuwe bijdragers op weg te helpen [label issues die eenvoudig genoeg zijn voor beginners om aan te pakken](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub zal deze issues vervolgens op verschillende plaatsen op het platform aan de oppervlakte brengen, waardoor nuttige bijdragen worden verhoogd en de wrijving wordt verminderd van gebruikers die problemen aanpakken die te moeilijk zijn voor hun niveau.
 * [GitHub's Open Source-enquête 2017](http://opensourcesurvey.org/2017/) vertoonde onvolledige of verwarrende documentatie is het grootste probleem voor open source-gebruikers. Goede documentatie nodigt uit tot interactie met uw project. Uiteindelijk zal iemand een issue of pull request openen. Gebruik deze interacties als kansen om ze door de trechter te verplaatsen.
 
 * **Als iemand nieuw op uw project komt, bedank hem dan voor zijn interesse!** Er is maar één negatieve ervaring nodig om ervoor te zorgen dat iemand niet meer terug wil komen.
@@ -178,7 +178,7 @@ Kijk of je manieren kunt vinden om het eigendom zoveel mogelijk met je gemeensch
 
 * **Geef elke bijdrager toegang tot commit.** @felixge ontdekte dat dit mensen [meer enthousiast maakte om hun patches op te poetsen](https://felixge.de/2013/03/11/the-pull-request-hack.html), en hij vond zelfs nieuwe beheerders voor projecten waaraan hij al een tijdje niet had gewerkt.
 
-* Als uw project zich op GitHub bevindt, **verplaats uw project dan van uw persoonlijke account naar een [Organisatie](https://help.github.com/articles/creating-a-new-organization-account/)** en voeg minstens één back-upbeheerder toe. Organisaties maken het gemakkelijker om met externe medewerkers aan projecten te werken.
+* Als uw project zich op GitHub bevindt, **verplaats uw project dan van uw persoonlijke account naar een [Organisatie](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** en voeg minstens één back-upbeheerder toe. Organisaties maken het gemakkelijker om met externe medewerkers aan projecten te werken.
 
 De realiteit is dat bij [de meeste projecten]
 (https://peerj.com/preprints/1233/) een of twee beheerders die het meeste werk doen. Hoe groter uw project en hoe groter uw gemeenschap, hoe gemakkelijker het is om hulp te vinden.
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index ec0ec98ce9a..a1bfc27689c 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -453,7 +453,7 @@ Als u uw idee nergens anders kunt vinden, bent u klaar om een ​​stap te zett
 
 Voordat je een issue of pull request opent, controleer je de bijdragende documenten van het project (meestal een bestand genaamd CONTRIBUTING, of in de README), om te zien of je iets specifieks moet opnemen. Ze kunnen u bijvoorbeeld vragen een sjabloon te volgen, of eisen dat u tests gebruikt.
 
-Als je een substantiële bijdrage wilt leveren, open dan een vraagstuk voordat je eraan gaat werken. Het is handig om het project een tijdje te bekijken (op GitHub, [u kunt op "Bekijken" klikken](https://help.github.com/articles/watching-repositories/) om op de hoogte te worden gehouden van alle gesprekken), en ken de leden van de gemeenschap voordat u werk gaat doen dat misschien niet wordt geaccepteerd.
+Als je een substantiële bijdrage wilt leveren, open dan een vraagstuk voordat je eraan gaat werken. Het is handig om het project een tijdje te bekijken (op GitHub, [u kunt op "Bekijken" klikken](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) om op de hoogte te worden gehouden van alle gesprekken), en ken de leden van de gemeenschap voordat u werk gaat doen dat misschien niet wordt geaccepteerd.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -491,7 +491,7 @@ Een pull-verzoek hoeft niet het voltooide werk te vertegenwoordigen. Het is mees
 
 Als het project op GitHub staat, kun je als volgt een pull-aanvraag indienen:
 
-* **[Fork the repository](https://guides.github.com/activities/forking/)** en kloon het lokaal. Verbind uw locale met de originele "upstream" repository door deze toe te voegen als een remote. Haal vaak wijzigingen van "upstream" binnen, zodat u up-to-date blijft, zodat wanneer u uw pull-verzoek indient, samenvoegingsconflicten minder waarschijnlijk zijn. (Zie meer gedetailleerde instructies [hier](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork the repository](https://guides.github.com/activities/forking/)** en kloon het lokaal. Verbind uw locale met de originele "upstream" repository door deze toe te voegen als een remote. Haal vaak wijzigingen van "upstream" binnen, zodat u up-to-date blijft, zodat wanneer u uw pull-verzoek indient, samenvoegingsconflicten minder waarschijnlijk zijn. (Zie meer gedetailleerde instructies [hier](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Maak een branch aan](https://guides.github.com/introduction/flow/)** voor uw bewerkingen.
 * **Verwijs naar relevante problemen (_issues_)** of ondersteunende documentatie in uw PR (bijvoorbeeld 'Closes #37'.)
 * **Voeg schermafbeeldingen toe van de voor en na** als uw wijzigingen verschillen in HTML / CSS bevatten. Sleep de afbeeldingen naar de hoofdtekst van uw pull-aanvraag.
diff --git a/_articles/nl/leadership-and-governance.md b/_articles/nl/leadership-and-governance.md
index 785e0c561c6..3e289a50089 100644
--- a/_articles/nl/leadership-and-governance.md
+++ b/_articles/nl/leadership-and-governance.md
@@ -79,7 +79,7 @@ Als u eenmaal leiderschapsrollen heeft vastgesteld, vergeet dan niet te document
 
 Tools zoals [Vossibility](https://github.com/icecrime/vossibility-stack) kunnen je helpen om publiekelijk bij te houden wie (of niet) bijdraagt ​​aan het project. Door deze informatie te documenteren, wordt de perceptie van de gemeenschap vermeden dat beheerders een kliek zijn die privé beslissingen neemt.
 
-Ten slotte, als uw project op GitHub staat, overweeg dan om uw project van uw persoonlijke account naar een organisatie te verplaatsen en ten minste één back-upbeheerder toe te voegen. [GitHub Organisations](https://help.github.com/articles/creating-a-new-organization-account/) maken het gemakkelijker om machtigingen en meerdere opslagplaatsen te beheren en de nalatenschap van je project te beschermen via [gedeeld eigendom](../building-community/#deel-het-eigendom-van-uw-project).
+Ten slotte, als uw project op GitHub staat, overweeg dan om uw project van uw persoonlijke account naar een organisatie te verplaatsen en ten minste één back-upbeheerder toe te voegen. [GitHub Organisations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) maken het gemakkelijker om machtigingen en meerdere opslagplaatsen te beheren en de nalatenschap van je project te beschermen via [gedeeld eigendom](../building-community/#deel-het-eigendom-van-uw-project).
 
 ## Wanneer moet ik iemand commit-toegang geven?
 
@@ -87,7 +87,7 @@ Sommige mensen vinden dat je commitment moet geven aan iedereen die een bijdrage
 
 Aan de andere kant, vooral voor grotere, meer complexe projecten, wil je misschien alleen commitment geven aan mensen die hun betrokkenheid hebben getoond. Er is niet één goede manier om het te doen - doe wat je het prettigst vindt!
 
-Als je project op GitHub staat, kun je [beschermde branches](https://help.github.com/articles/about-protected-branches/) gebruiken om te beheren wie naar een bepaalde branch kan pushen, en onder welke omstandigheden.
+Als je project op GitHub staat, kun je [beschermde branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) gebruiken om te beheren wie naar een bepaalde branch kan pushen, en onder welke omstandigheden.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 08390034ef1..c41fa1a3bd4 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -28,7 +28,7 @@ Ten slotte kan uw project afhankelijkheden hebben met licentievereisten waarvan
 
 ## Zijn openbare GitHub-projecten open source?
 
-Wanneer je [een nieuw project maakt](https://help.github.com/articles/creating-a-new-repository/) op GitHub, heb je de optie om de repository **privé** of **openbaar te maken**.
+Wanneer je [een nieuw project maakt](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) op GitHub, heb je de optie om de repository **privé** of **openbaar te maken**.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Je hebt geluk, want tegenwoordig zijn open source-licenties gestandaardiseerd en
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) en [GPLv3](https://choicealicense.com/licenses/gpl-3.0/) zijn de meest populaire open source-licenties, maar er zijn andere opties om uit te kiezen. U kunt de volledige tekst van deze licenties en instructies voor het gebruik ervan vinden op [choosealicense.com](https://choosealicense.com/).
 
-Wanneer u een nieuw project op GitHub maakt, wordt u [gevraagd om een licentie toe te voegen](https://help.github.com/articles/open-source-licensing/).
+Wanneer u een nieuw project op GitHub maakt, wordt u [gevraagd om een licentie toe te voegen](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -91,7 +91,7 @@ Als alternatief kunt u bijdragers van tevoren laten instemmen (via een aanvullen
 
 ## Heeft mijn project een aanvullende contribuantenovereenkomst nodig?
 
-Waarschijnlijk niet. Voor de overgrote meerderheid van open source-projecten dient een open source-licentie impliciet als zowel de inkomende (van bijdragers) als uitgaande (naar andere bijdragers en gebruikers) licentie. Als uw project zich op GitHub bevindt, maken de Servicevoorwaarden van GitHub "inbound = outbound" tot de [expliciete standaard](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Waarschijnlijk niet. Voor de overgrote meerderheid van open source-projecten dient een open source-licentie impliciet als zowel de inkomende (van bijdragers) als uitgaande (naar andere bijdragers en gebruikers) licentie. Als uw project zich op GitHub bevindt, maken de Servicevoorwaarden van GitHub "inbound = outbound" tot de [expliciete standaard](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Een aanvullende bijdragersovereenkomst -- vaak een bijdragerslicentieovereenkomst (CLA) genoemd -- kan administratief werk creëren voor projectbeheerders. Hoeveel werk een overeenkomst toevoegt, hangt af van het project en de uitvoering. Een eenvoudige overeenkomst kan vereisen dat bijdragers met een klik bevestigen dat ze de benodigde rechten hebben om bij te dragen onder de open source-licentie van het project. Een meer gecompliceerde overeenkomst vereist mogelijk juridische beoordeling en goedkeuring door de werkgevers van contribuanten.
 
diff --git a/_articles/nl/metrics.md b/_articles/nl/metrics.md
index 26712b18123..e3799121bc0 100644
--- a/_articles/nl/metrics.md
+++ b/_articles/nl/metrics.md
@@ -37,7 +37,7 @@ Voordat iemand uw project kan gebruiken of eraan kan bijdragen, moet hij of zij
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Als je project wordt gehost op GitHub, [je kunt zien](https://help.github.com/articles/about-repository-graphs/#traffic) hoeveel mensen op je project terechtkomen en waar ze vandaan komen. Klik op de pagina van uw project op "Insights" en vervolgens op "Traffic". Op deze pagina ziet u:
+Als je project wordt gehost op GitHub, [je kunt zien](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) hoeveel mensen op je project terechtkomen en waar ze vandaan komen. Klik op de pagina van uw project op "Insights" en vervolgens op "Traffic". Op deze pagina ziet u:
 
 * **Total page views:** geeft aan hoe vaak uw project is bekeken
 
@@ -47,7 +47,7 @@ Als je project wordt gehost op GitHub, [je kunt zien](https://help.github.com/ar
 
 * **Populaire content:** vertelt u waar bezoekers naartoe gaan in uw project, uitgesplitst naar paginaweergaven en unieke bezoekers.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) kan ook helpen bij het geven van een basismeting van populariteit. Hoewel GitHub-sterren niet noodzakelijkerwijs verband houden met downloads en gebruik, kunnen ze u wel vertellen hoeveel mensen kennis nemen van uw werk.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) kan ook helpen bij het geven van een basismeting van populariteit. Hoewel GitHub-sterren niet noodzakelijkerwijs verband houden met downloads en gebruik, kunnen ze u wel vertellen hoeveel mensen kennis nemen van uw werk.
 
 U kunt ook [vindbaarheid op specifieke plaatsen bijhouden](https://opensource.com/business/16/6/pirate-metrics): bijvoorbeeld Google PageRank, verwijzingsverkeer van de website van uw project of verwijzingen van andere open bronprojecten of websites.
 
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index e54ee5c9ed1..570d79162b4 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -115,9 +115,9 @@ Over het algemeen moet u uw project openen als u zich op uw gemak voelt als ande
 
 Ongeacht in welke fase u besluit uw project te openen, elk project moet de volgende documentatie bevatten:
 
-* [Open source-licentie](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)
-* [Richtlijnen voor het bijdragen](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Open source-licentie](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Richtlijnen voor het bijdragen](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Gedragscode](../code-of-conduct/)
 
 Als open source-onderhouder helpen deze componenten u bij het communiceren van verwachtingen, het beheren van bijdragen en het beschermen van ieders wettelijke rechten (inclusief die van uzelf). Ze vergroten uw kansen op een positieve ervaring aanzienlijk.
@@ -194,7 +194,7 @@ Na verloop van tijd kunt u andere veelgestelde vragen aan uw CONTRIBUTING-bestan
 
 Voor meer hulp bij het schrijven van je CONTRIBUTING-bestand, ga je naar @nayafia's [sjabloon voor bijdrage gids](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) of @mozilla's ["Bouw een CONTRIBUTING.md workshop"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Link naar uw BIJDRAGEN-bestand vanuit uw README, zodat meer mensen het kunnen zien. Als je [het CONTRIBUTING-bestand in de repository van je project plaatst](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), zal GitHub automatisch naar je bestand linken wanneer een bijdrager een issue maakt of opent een pull-verzoek.
+Link naar uw BIJDRAGEN-bestand vanuit uw README, zodat meer mensen het kunnen zien. Als je [het CONTRIBUTING-bestand in de repository van je project plaatst](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), zal GitHub automatisch naar je bestand linken wanneer een bijdrager een issue maakt of opent een pull-verzoek.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -273,7 +273,7 @@ Het is niet nodig om een stijlgids voor je project te schrijven als je net begin
 
 ## Uw checklist vóór de lancering
 
-Klaar om uw project te openen? Hier is een checklist om te helpen. Alle vakjes aanvinken? Je bent klaar om te gaan! [Klik op "publiceren"](https://help.github.com/articles/making-a-private-repository-public/) en geef jezelf een schouderklopje.
+Klaar om uw project te openen? Hier is een checklist om te helpen. Alle vakjes aanvinken? Je bent klaar om te gaan! [Klik op "publiceren"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) en geef jezelf een schouderklopje.
 
 **Documentatie**
 
diff --git a/_articles/pcm/best-practices.md b/_articles/pcm/best-practices.md
index 785dc0e87e1..cdb25ab028b 100644
--- a/_articles/pcm/best-practices.md
+++ b/_articles/pcm/best-practices.md
@@ -147,7 +147,7 @@ You no need to do everything alone. Your project community dey exist for one rea
 
 If you dey find people wey go fit help, start to ask around.
 
-One way to get new contributors be to [label issues wey dey simple for beginners to work on](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub go show these issues for different places for the platform, e go make them dey easier to see.
+One way to get new contributors be to [label issues wey dey simple for beginners to work on](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub go show these issues for different places for the platform, e go make them dey easier to see.
 
 When you see new contributors wey dey make repeated contributions, make you acknowledge their work and give them more responsibility. Write down how other people fit grow into leadership roles if them wan. Make you encourage others to [share ownership of the project](../building-community/#share-the-person-waeh-get-your-project) because e fit reduce your own workload, just like @lmccart find out for her project, [p5.js](https://github.com/processing/p5.js).
 
@@ -195,7 +195,7 @@ One important way wey you fit automate your project be to add tests.
 
 Tests fit make contributors dey confident say them no go spoil anything. Them still dey make am easy for you to review and accept contributions quickly. The more responsive you dey, the more engaged your community fit dey.
 
-Set up automatic tests wey go run on all incoming contributions, and make sure say your tests dey easy to run locally by contributors. You must require say all code contributions must pass your tests before them fit submit am. You go help set one minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) for GitHub fit help ensure say no change go enter if your tests no pass.
+Set up automatic tests wey go run on all incoming contributions, and make sure say your tests dey easy to run locally by contributors. You must require say all code contributions must pass your tests before them fit submit am. You go help set one minimum standard of quality for all submissions. [Required status checks](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) for GitHub fit help ensure say no change go enter if your tests no pass.
 
 If you add tests, make sure say you explain how them dey work for your CONTRIBUTING file.
 
diff --git a/_articles/pcm/building-community.md b/_articles/pcm/building-community.md
index b4dda5686fc..3e332fe2be5 100644
--- a/_articles/pcm/building-community.md
+++ b/_articles/pcm/building-community.md
@@ -28,7 +28,7 @@ Start with your documentation:
 
 * **Make am easy for person to use your project.** [One friendly README](../starting-a-project/#writing-a-readme) and clear code examples fit make am easier for anybody wey land for your project to begin.
 * **Explain contribution make aeh clear**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and make sure say your issues dey up-to-date.
-* **Good first issues**: To helep tear rubber contributors start, think am say [labeling issues wey dey simple for beginners to handle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub go show these issues for different places for the platform, e go increase useful contributions and reduce friction for people wey wan handle issues wey too hard for their level.
+* **Good first issues**: To helep tear rubber contributors start, think am say [labeling issues wey dey simple for beginners to handle](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub go show these issues for different places for the platform, e go increase useful contributions and reduce friction for people wey wan handle issues wey too hard for their level.
 
 [GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) talk say incomplete or confusing documentation na the biggest problem wey open source users dey face. Good documentation go invite people to interact with your project. E fit happen say one person go open an issue or pull request. Use these interactions as opportunities to waka them down the funnel.
 
@@ -161,7 +161,7 @@ Try look for ways wey you fit share this ownership with your community as much a
 
 * **Give every contributor access to commit.** @felixge see say this one dey ginger people, e make dem dey shine their patches [more](https://felixge.de/2013/03/11/the-pull-request-hack.html), and e even find new maintainers for projects wey e never dey touch for long.
 
-* If your project dey on GitHub, **move your project from your personal account go [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations dey make am easy to work with external people.
+* If your project dey on GitHub, **move your project from your personal account go [Organization](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** and add at least one backup admin. Organizations dey make am easy to work with external people.
 
 The fact na say [most projects get](https://peerj.com/preprints/1233/) only one or two maintainers wey dey do plenty work. As your project dey grow or your community dey big pass, e go dey easy to find help.
 
diff --git a/_articles/pcm/how-to-contribute.md b/_articles/pcm/how-to-contribute.md
index 66069df4977..997f3efe6c5 100644
--- a/_articles/pcm/how-to-contribute.md
+++ b/_articles/pcm/how-to-contribute.md
@@ -447,7 +447,7 @@ If you can't find your idea elsewhere, you're ready to make a move. If the proje
 
 Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests.
 
-If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted.
+If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) to be notified of all conversations), and get to know community members, before doing work that might not get accepted.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -482,7 +482,7 @@ A pull request doesn't have to represent finished work. It's usually better to o
 
 If the project is on GitHub, here's how to submit a pull request:
 
-* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
 * **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
 * **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
diff --git a/_articles/pcm/leadership-and-governance.md b/_articles/pcm/leadership-and-governance.md
index ce7b8356aae..9e7f4d050a6 100644
--- a/_articles/pcm/leadership-and-governance.md
+++ b/_articles/pcm/leadership-and-governance.md
@@ -73,7 +73,7 @@ Once you've established leadership roles, don't forget to document how people ca
 
 Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately.
 
-Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-the-person-waeh-get-your-project).
+Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-the-person-waeh-get-your-project).
 
 ## When should I give someone commit access?
 
@@ -81,7 +81,7 @@ Some people think you should give commit access to everybody who makes a contrib
 
 On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable!
 
-If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances.
+If your project is on GitHub, you can use [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) to manage who can push to a particular branch, and under which circumstances.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/pcm/legal.md b/_articles/pcm/legal.md
index 9e4e56e7f9d..f446c363e3e 100644
--- a/_articles/pcm/legal.md
+++ b/_articles/pcm/legal.md
@@ -28,7 +28,7 @@ Finally, your project may have dependencies with license requirements that you w
 
 ## Are public GitHub projects open source?
 
-When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**.
+When you [create a new project](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) on GitHub, you have the option to make the repository **private** or **public**.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ You're in luck, because today, open source licenses are standardized and easy to
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
 
-When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+When you create a new project on GitHub, you'll be [asked to add a license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -90,7 +90,7 @@ Alternatively, you can have contributors pre-approve certain license changes via
 
 ## Does my project need an additional contributor agreement?
 
-Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers.
 
diff --git a/_articles/pcm/metrics.md b/_articles/pcm/metrics.md
index 4a3142522e7..7e68f180de9 100644
--- a/_articles/pcm/metrics.md
+++ b/_articles/pcm/metrics.md
@@ -37,7 +37,7 @@ Before anybody can use or contribute back to your project, they need to know it
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see:
+If your project is hosted on GitHub, [you can view](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see:
 
 * **Total page views:** Tells you how many times your project was viewed
 
@@ -47,7 +47,7 @@ If your project is hosted on GitHub, [you can view](https://help.github.com/arti
 
 * **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
 
 You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites.
 
diff --git a/_articles/pcm/starting-a-project.md b/_articles/pcm/starting-a-project.md
index 4743356f189..6d0179693c8 100644
--- a/_articles/pcm/starting-a-project.md
+++ b/_articles/pcm/starting-a-project.md
@@ -106,9 +106,9 @@ Generally speaking, you should open source your project when you feel comfortabl
 
 No matter which stage you decide to open source your project, every project should include the following documentation:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience.
@@ -182,7 +182,7 @@ Over time, you might add other frequently asked questions to your CONTRIBUTING f
 
 For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
+Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ It isn't necessary to write a style guide for your project when you're just star
 
 ## Your pre-launch checklist
 
-Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back.
+Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) and pat yourself on the back.
 
 **Documentation**
 
diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md
index e15b7cd62c4..773501fa907 100644
--- a/_articles/pl/best-practices.md
+++ b/_articles/pl/best-practices.md
@@ -167,7 +167,7 @@ Nie musisz robić wszystkiego sam. Społeczność twojego projektu nie istnieje
 
 Jeśli szukasz innych osób, zacznij od pytania.
 
-Jednym ze sposobów na pozyskanie nowych współpracowników jest jawne [label issues które są wystarczająco proste dla początkujących](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub wyświetli te problemy w różnych miejscach platformy, zwiększając ich widoczność.
+Jednym ze sposobów na pozyskanie nowych współpracowników jest jawne [label issues które są wystarczająco proste dla początkujących](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub wyświetli te problemy w różnych miejscach platformy, zwiększając ich widoczność.
 
 Gdy zobaczysz, że nowi współautorzy wnoszą powtarzający się wkład, rozpoznaj ich pracę, oferując większą odpowiedzialność. Udokumentuj, w jaki sposób inni mogą stać się przywódcami, jeśli chcą.
 
@@ -219,7 +219,7 @@ Jednym z najważniejszych sposobów automatyzacji projektu jest dodanie testów.
 
 Testy pomagają współpracownikom mieć pewność, że niczego nie zniszczą. Ułatwiają także szybkie przeglądanie i przyjmowanie wkładów. Im bardziej jesteś responsywny, tym bardziej zaangażowana może być twoja społeczność.
 
-Skonfiguruj automatyczne testy, które będą przeprowadzane na wszystkich przychodzących kontrybucjach, i upewnij się, że twoje testy mogą być łatwo uruchomione lokalnie przez autorów. Wymagaj, aby wszystkie elementy kodu pomyślnie przeszły testy, zanim będą mogły zostać przesłane. Pomożesz ustalić minimalny standard jakości wszystkich zgłoszeń. [Wymagane kontrole statusu](https://help.github.com/articles/about-required-status-checks/) na GitHub mogą pomóc zapewnić, że żadna zmiana nie zostanie scalona bez pozytywnego wyniku testów.
+Skonfiguruj automatyczne testy, które będą przeprowadzane na wszystkich przychodzących kontrybucjach, i upewnij się, że twoje testy mogą być łatwo uruchomione lokalnie przez autorów. Wymagaj, aby wszystkie elementy kodu pomyślnie przeszły testy, zanim będą mogły zostać przesłane. Pomożesz ustalić minimalny standard jakości wszystkich zgłoszeń. [Wymagane kontrole statusu](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) na GitHub mogą pomóc zapewnić, że żadna zmiana nie zostanie scalona bez pozytywnego wyniku testów.
 
 Jeśli dodasz testy, wyjaśnij, jak działają w pliku CONTRIBUTING.
 
diff --git a/_articles/pl/building-community.md b/_articles/pl/building-community.md
index ea217246994..fad03aed592 100644
--- a/_articles/pl/building-community.md
+++ b/_articles/pl/building-community.md
@@ -28,7 +28,7 @@ Zacznij od dokumentacji:
 
 * **Ułatw innym korzystanie z Twojego projektu.** [Przyjazny README](../starting-a-project/#pisanie-readme) jasne przykłady kodu ułatwią rozpoczęcie pracy każdemu, kto wyląduje na Twoim projekcie.
 * **Wyjaśnij, jak wnieść wkład**, używając [twój plik CONTRIBUTING](../starting-a-project/#pisanie-swoich-wytycznych) i aktualizując swoje issues.
-* **Dobre pierwsze issues**: Aby pomóc nowym autorom w rozpoczęciu pracy, rozważ wyraźnie [problemy z etykietowaniem, które są na tyle proste, że początkujący mogą je rozwiązać](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub wyświetli te problemy w różnych miejscach na platformie, zwiększając użyteczny wkład i zmniejszając tarcie ze strony użytkowników zajmujących się problemami, które są zbyt trudne dla ich poziomu.
+* **Dobre pierwsze issues**: Aby pomóc nowym autorom w rozpoczęciu pracy, rozważ wyraźnie [problemy z etykietowaniem, które są na tyle proste, że początkujący mogą je rozwiązać](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub wyświetli te problemy w różnych miejscach na platformie, zwiększając użyteczny wkład i zmniejszając tarcie ze strony użytkowników zajmujących się problemami, które są zbyt trudne dla ich poziomu.
 
 [Ankieta GitHuba 2017 Open Source](http://opensourcesurvey.org/2017/) wykazała, że niekompletna lub myląca dokumentacja jest największym problemem dla użytkowników open source. Dobra dokumentacja zachęca ludzi do interakcji z Twoim projektem. W końcu ktoś otworzy problem lub wyciągnie prośbę. Użyj tych interakcji jako okazji do przeniesienia ich w dół ścieżki.
 
@@ -175,7 +175,7 @@ Sprawdź, czy możesz w jak największym stopniu znaleźć sposób na dzielenie
 
 * **Daj dostęp każdemu współautorowi.** @felixge stwierdził, że to sprawiło, że ludzie są [bardziej podekscytowani dopracowywaniem swoich łat](https://felixge.de/2013/03/11/the-pull-request-hack.html), a nawet znalazł nowych opiekunów dla projektów, nad którymi on od jakiegoś czasu nie pracował.
 
-* Jeśli Twój projekt jest w serwisie GitHub, **przenieś swój projekt z konta osobistego do [Organizacji](https://help.github.com/articles/creating-a-new-organization-account/)** i dodaj co najmniej jednego administratora kopii zapasowych. Organizacje ułatwiają pracę nad projektami z zewnętrznymi współpracownikami.
+* Jeśli Twój projekt jest w serwisie GitHub, **przenieś swój projekt z konta osobistego do [Organizacji](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** i dodaj co najmniej jednego administratora kopii zapasowych. Organizacje ułatwiają pracę nad projektami z zewnętrznymi współpracownikami.
 
 Rzeczywistość jest taka, że [większość projektów ma tylko](https://peerj.com/preprints/1233/) jednego lub dwóch opiekunów, którzy wykonują większość pracy. Im większy projekt i większa społeczność, tym łatwiej jest znaleźć pomoc.
 
diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index efadc381ecf..336fd63aa32 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -447,7 +447,7 @@ Jeśli nie możesz znaleźć swojego pomysłu w innym miejscu, możesz zrobić k
 
 Zanim otworzysz problem lub pull request, sprawdź dokumenty wspierające projekt (zwykle plik o nazwie CONTRIBUTING lub w README), aby sprawdzić, czy musisz dołączyć coś konkretnego. Na przykład projekt może wymagać przestrzegania szablonu lub użycia testów.
 
-Jeśli chcesz wnieść znaczący wkład, otwórz problem, który chcesz rozwiązać, zanim zaczniesz nad nim pracować. Przydatne jest obserwowanie projektu przez jakiś czas (na GitHub, [możesz kliknąć "Watch"](https://help.github.com/articles/watching-repositories/) aby otrzymywać powiadomienia o wszystkich rozmowach) i poznać członków społeczności przed podjęciem pracy, która może nie zostać zaakceptowana.
+Jeśli chcesz wnieść znaczący wkład, otwórz problem, który chcesz rozwiązać, zanim zaczniesz nad nim pracować. Przydatne jest obserwowanie projektu przez jakiś czas (na GitHub, [możesz kliknąć "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) aby otrzymywać powiadomienia o wszystkich rozmowach) i poznać członków społeczności przed podjęciem pracy, która może nie zostać zaakceptowana.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -482,7 +482,7 @@ Pull request nie musi reprezentować ukończonej pracy. Zwykle lepiej jest wcze
 
 Jeśli projekt znajduje się na GitHub, oto jak przesłać pull request:
 
-* **[Fork repozytorium](https://guides.github.com/activities/forking/)** i jego klon lokalnie. Podłącz swoje lokalne repozytorium do oryginalnego„upstream”, dodając je jako remote. Pobieraj zmiany z „upstream” często, abyś był na bieżąco, aby po stworzeniu pull requesta konflikty w kodzie były mniej prawdopodobne. (Zobacz bardziej szczegółowe instrukcje [tutaj](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork repozytorium](https://guides.github.com/activities/forking/)** i jego klon lokalnie. Podłącz swoje lokalne repozytorium do oryginalnego„upstream”, dodając je jako remote. Pobieraj zmiany z „upstream” często, abyś był na bieżąco, aby po stworzeniu pull requesta konflikty w kodzie były mniej prawdopodobne. (Zobacz bardziej szczegółowe instrukcje [tutaj](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Stworzenie brancha](https://guides.github.com/introduction/flow/)** dla swoich zmian.
 * **Odniesienie się do wszelkich istotnych issues** lub dokumentacja uzupełniająca w twoim PR (na przykład, "Closes #37.")
 * **Dołączenie zrzutów ekranu przed i po** jeśli zmiany zawierają różnice w HTML / CSS. Przeciągnij i upuść obrazy w treści pull requesta.
diff --git a/_articles/pl/leadership-and-governance.md b/_articles/pl/leadership-and-governance.md
index 6b434c0b13c..0c6155a09b7 100644
--- a/_articles/pl/leadership-and-governance.md
+++ b/_articles/pl/leadership-and-governance.md
@@ -77,7 +77,7 @@ Po ustaleniu ról przywódczych nie zapomnij udokumentować, w jaki sposób ludz
 
 Narzędzia jak [Vossibility](https://github.com/icecrime/vossibility-stack) mogą pomóc Ci publicznie śledzić, kto przyczynia się (lub nie) do projektu. Dokumentowanie tych informacji pozwala uniknąć postrzegania przez społeczność, że opiekunowie są kliką, która podejmuje decyzje prywatnie.
 
-Wreszcie, jeśli Twój projekt jest w GitHub, rozważ przeniesienie projektu z konta osobistego do organizacji i dodanie co najmniej jednego administratora kopii zapasowych. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) ułatwiają zarządzanie uprawnieniami i wieloma repozytoriami oraz chronią dziedzictwo projektu poprzez [współwłasność](../building-community/#udostępnij-własność-swojego-projektu).
+Wreszcie, jeśli Twój projekt jest w GitHub, rozważ przeniesienie projektu z konta osobistego do organizacji i dodanie co najmniej jednego administratora kopii zapasowych. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) ułatwiają zarządzanie uprawnieniami i wieloma repozytoriami oraz chronią dziedzictwo projektu poprzez [współwłasność](../building-community/#udostępnij-własność-swojego-projektu).
 
 ## Kiedy powinienem dać komuś dostęp?
 
@@ -85,7 +85,7 @@ Niektórzy uważają, że powinieneś dać dostęp do zatwierdzenia każdemu, kt
 
 Z drugiej strony, szczególnie w przypadku większych, bardziej złożonych projektów, możesz chcieć dać dostęp do zatwierdzania tylko osobom, które wykazały swoje zaangażowanie. Nie ma jednego właściwego sposobu - rób to, co najbardziej Ci odpowiada!
 
-Jeśli Twój projekt znajduje się na GitHub, możesz użyć [protected branches](https://help.github.com/articles/about-protected-branches/) zarządzać, kto może naciskać na konkretny branch i w jakich okolicznościach.
+Jeśli Twój projekt znajduje się na GitHub, możesz użyć [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) zarządzać, kto może naciskać na konkretny branch i w jakich okolicznościach.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 21f83e4cf1a..4958c490044 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -28,11 +28,11 @@ Wreszcie, twój projekt może być zależny od wymagań licencyjnych, o których
 
 ## Czy publiczne projekty GitHub są open source?
 
-Kiedy [tworzysz nowy projekt](https://help.github.com/articles/creating-a-new-repository/) na GitHub masz opcję utworzenia repozytorium **private** lub **public**.
+Kiedy [tworzysz nowy projekt](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) na GitHub masz opcję utworzenia repozytorium **private** lub **public**.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
-**Upublicznienie projektu GitHub to nie to samo, co licencjonowanie projektu.** Projekty publiczne są objęte [Warunkami świadczenia usług GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-licytations-grants), który pozwala innym przeglądać i rozwidlać twój projekt, ale w przeciwnym razie twoja praca nie ma żadnych uprawnień.
+**Upublicznienie projektu GitHub to nie to samo, co licencjonowanie projektu.** Projekty publiczne są objęte [Warunkami świadczenia usług GitHub](https://docs.github.com/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), który pozwala innym przeglądać i rozwidlać twój projekt, ale w przeciwnym razie twoja praca nie ma żadnych uprawnień.
 
 Jeśli chcesz, aby inni używali, rozpowszechniali, modyfikowali lub wnieśli swój wkład z powrotem do twojego projektu, musisz dołączyć licencję typu open source. Na przykład, ktoś nie może legalnie wykorzystywać żadnej części twojego projektu GitHub w swoim kodzie, nawet jeśli jest on publiczny, chyba że wyraźnie mu to umożliwisz.
 
@@ -42,7 +42,7 @@ Masz szczęście, ponieważ dziś licencje open source są ustandaryzowane i ła
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), i [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) są najpopularniejszymi licencjami typu open source, ale istnieją inne opcje do wyboru. Możesz znaleźć pełny tekst tych licencji i instrukcje, jak z nich korzystać, na [choosealicense.com](https://choosealicense.com/).
 
-Kiedy tworzysz nowy projekt w GitHub, zostaniesz [poproszony o dodanie licencji](https://help.github.com/articles/open-source-licensing/).
+Kiedy tworzysz nowy projekt w GitHub, zostaniesz [poproszony o dodanie licencji](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -90,7 +90,7 @@ Ewentualnie możesz poprosić autorów o wcześniejsze uzgodnienie (za pośredni
 
 ## Czy mój projekt wymaga dodatkowej umowy wnoszącej wkład?
 
-Prawdopodobnie nie. W zdecydowanej większości projektów typu open source licencja typu open source domyślnie służy zarówno jako licencja przychodząca (od współpracowników), jak i wychodząca (dla innych autorów i użytkowników). Jeśli Twój projekt działa na GitHub, Warunki korzystania z usługi GitHub sprawiają, że „przychodzące = wychodzące” jest [jawnym domyślnym](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Prawdopodobnie nie. W zdecydowanej większości projektów typu open source licencja typu open source domyślnie służy zarówno jako licencja przychodząca (od współpracowników), jak i wychodząca (dla innych autorów i użytkowników). Jeśli Twój projekt działa na GitHub, Warunki korzystania z usługi GitHub sprawiają, że „przychodzące = wychodzące” jest [jawnym domyślnym](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Dodatkowa umowa współtwórcy - często zwana umową licencyjną współtwórcy (CLA) - może tworzyć prace administracyjne dla opiekunów projektów. Ile pracy dodaje umowa zależy od projektu i realizacji. Prosta umowa może wymagać, aby uczestnicy potwierdzili jednym kliknięciem, że mają prawa niezbędne do wniesienia wkładu w ramach licencji open source projektu. Bardziej skomplikowana umowa może wymagać weryfikacji prawnej i wypisania się od pracodawców współpracowników.
 
diff --git a/_articles/pl/metrics.md b/_articles/pl/metrics.md
index 64d0d259e70..bb634987aca 100644
--- a/_articles/pl/metrics.md
+++ b/_articles/pl/metrics.md
@@ -37,7 +37,7 @@ Zanim ktokolwiek będzie mógł wykorzystać Twój projekt lub wesprzeć go, mus
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Jeśli Twój projekt jest hostowany na GitHub, [możesz zobaczyć](https://help.github.com/articles/about-repository-graphs/#traffic), ile osób wylądowało na twoim projekcie i skąd pochodzi. Na stronie projektu kliknij „Statystyki”, a następnie „Ruch”. Na tej stronie możesz zobaczyć:
+Jeśli Twój projekt jest hostowany na GitHub, [możesz zobaczyć](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository), ile osób wylądowało na twoim projekcie i skąd pochodzi. Na stronie projektu kliknij „Statystyki”, a następnie „Ruch”. Na tej stronie możesz zobaczyć:
 
 * **Łączna liczba wyświetleń strony:** Informuje, ile razy Twój projekt był oglądany
 
@@ -47,7 +47,7 @@ Jeśli Twój projekt jest hostowany na GitHub, [możesz zobaczyć](https://help.
 
 * **Popularna treść:** Informuje, gdzie odwiedzają Twój projekt, w podziale na wyświetlenia stron i unikalnych użytkowników.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) może również pomóc w zapewnieniu podstawowej miary popularności. Chociaż gwiazdy GitHub niekoniecznie korelują z pobieraniem i użytkowaniem, mogą powiedzieć, ile osób zwraca uwagę na Twoją pracę.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) może również pomóc w zapewnieniu podstawowej miary popularności. Chociaż gwiazdy GitHub niekoniecznie korelują z pobieraniem i użytkowaniem, mogą powiedzieć, ile osób zwraca uwagę na Twoją pracę.
 
 Możesz także chcieć [śledzić wykrywalność w określonych miejscach](https://opensource.com/business/16/6/pirate-metrics): na przykład Google PageRank, ruch z odsyłaczy z witryny Twojego projektu lub skierowania z innych otwartych projekty źródłowe lub strony internetowe.
 
diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index 72f3a6fa04b..1836ac0815c 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -112,9 +112,9 @@ Ogólnie rzecz biorąc, powinieneś otworzyć swój projekt, gdy czujesz się do
 
 Bez względu na to, na jakim etapie zdecydujesz się na otwarcie projektu, każdy projekt powinien zawierać następującą dokumentację:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 Jako opiekun, te komponenty pomogą ci komunikować oczekiwania, zarządzać składkami i chronić prawa wszystkich osób (w tym własnych). Znacząco zwiększają twoje szanse na pozytywne doświadczenie.
@@ -190,7 +190,7 @@ Z czasem możesz dodawać inne często zadawane pytania do pliku WKŁAD. Zapisan
 
 Aby uzyskać więcej pomocy w pisaniu pliku WKŁAD, sprawdź @nayafia [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) lub @mozilla ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Link do pliku CONTRIBUTING  z README, dzięki czemu więcej osób go zobaczy. Jeśli [umieścisz plik CONTRIBUTING w repozytorium swojego projektu](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub automatycznie doda link do Twojego pliku, gdy współtwórca utworzy problem lub otworzy żądanie ściągnięcia.
+Link do pliku CONTRIBUTING  z README, dzięki czemu więcej osób go zobaczy. Jeśli [umieścisz plik CONTRIBUTING w repozytorium swojego projektu](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub automatycznie doda link do Twojego pliku, gdy współtwórca utworzy problem lub otworzy żądanie ściągnięcia.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -267,7 +267,7 @@ Nie musisz pisać przewodnika po stylu dla swojego projektu, gdy dopiero zaczyna
 
 ## Twoja lista kontrolna przed uruchomieniem
 
-Gotowy do otwarcia twojego projektu? Oto lista kontrolna, która pomoże. Zaznacz wszystkie pola? Jesteś gotowy! [Kliknij „opublikuj”](https://help.github.com/articles/making-a-private-repository-public/) i poklep się po plecach.
+Gotowy do otwarcia twojego projektu? Oto lista kontrolna, która pomoże. Zaznacz wszystkie pola? Jesteś gotowy! [Kliknij „opublikuj”](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) i poklep się po plecach.
 
 **Dokumentacja**
 
diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md
index f772ed06c07..c168825df3a 100644
--- a/_articles/pt/best-practices.md
+++ b/_articles/pt/best-practices.md
@@ -213,7 +213,7 @@ Uma das mais importantes formas de automatizar seu projeto é adicionando testes
 
 Testes ajudam os contribuidores a sentirem-se confiantes de que eles não quebrarão nada. Testes também tornam mais fácil, para você, revisar e aceitar contribuições rapidamente. Quanto mais responsivo você é, mais engajada sua comunidade poderá ser.
 
-Configure testes automáticos que irão executar em todas as contribuições recebidas e garanta que seus teste poderão ser facilmente executados localmente por seus contribuidores. Exija que todas as contribuições de código passem em seus testes antes que possam ser submetidas. Você ajudará a definir um padrão mínimo de qualidade para todas as submissões. [Verificações de status obrigatórias](https://help.github.com/articles/about-required-status-checks/) no GitHub podem ajudar a garantir que nenhuma mudança seja aceita sem passar por seus testes.
+Configure testes automáticos que irão executar em todas as contribuições recebidas e garanta que seus teste poderão ser facilmente executados localmente por seus contribuidores. Exija que todas as contribuições de código passem em seus testes antes que possam ser submetidas. Você ajudará a definir um padrão mínimo de qualidade para todas as submissões. [Verificações de status obrigatórias](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) no GitHub podem ajudar a garantir que nenhuma mudança seja aceita sem passar por seus testes.
 
 Se você adicionar testes, tenha certeza de ter explicado como eles funcionam em seu arquivo de contribuição.
 
diff --git a/_articles/pt/building-community.md b/_articles/pt/building-community.md
index 89c93b66a5e..bd6bdcba702 100644
--- a/_articles/pt/building-community.md
+++ b/_articles/pt/building-community.md
@@ -164,7 +164,7 @@ Procure encontrar maneiras de compartilhar a propriedade com a sua comunidade o
 
 * **Dê permissão de commit para cada um dos contribuidores.** @felixge descobriu que isso fez as pessoas [mais entusiasmadas em polir suas modificações](https://felixge.de/2013/03/11/the-pull-request-hack.html), e até mesmo descobriu novos mantenedores para projetos que ele não havia trabalhado por algum tempo.
 
-* Se o seu projeto está no GitHub, **mova-o da sua conta pessoal para uma [Organização](https://help.github.com/articles/creating-a-new-organization-account/)** e adicione pelo menos um administrador de backup. As organizações fazem com que seja mais fácil trabalhar em projetos com colaboradores externos.
+* Se o seu projeto está no GitHub, **mova-o da sua conta pessoal para uma [Organização](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** e adicione pelo menos um administrador de backup. As organizações fazem com que seja mais fácil trabalhar em projetos com colaboradores externos.
 
 A verdade é que [a maioria dos projetos tem somente](https://peerj.com/preprints/1233/) um ou dois mantenedores que fazem a maior parte do trabalho. Quanto maior o seu projeto, e maior a sua comunidade, mais fácil é encontrar ajuda.
 
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index 29b1bad4ad8..6f0da46598c 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -433,7 +433,7 @@ Se você não encontrar sua ideia em outro lugar, você está pronto para fazer
 
 Antes de abrir uma issue ou pull request, verifique os documentos de contribuição do projeto (geralmente um arquivo chamado CONTRIBUTING ou no README), para ver se é necessário incluir algo específico. Por exemplo, eles podem pedir que você siga um modelo ou exigir que você use testes.
 
-Se você quiser fazer uma contribuição substancial, abra uma issue para perguntar antes de trabalhar nela. É útil olhar o projeto por um tempo (no GitHub, [você pode clicar em "Watch"](https://help.github.com/articles/watching-repositories/) para ser notificado de todas as conversas) e conhecer os membros da comunidade, antes de realizar trabalhos que possam não ser aceitos.
+Se você quiser fazer uma contribuição substancial, abra uma issue para perguntar antes de trabalhar nela. É útil olhar o projeto por um tempo (no GitHub, [você pode clicar em "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) para ser notificado de todas as conversas) e conhecer os membros da comunidade, antes de realizar trabalhos que possam não ser aceitos.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -468,7 +468,7 @@ Um pull request não precisa representar o trabalho final. Geralmente, é melhor
 
 Se o projeto estiver no GitHub, veja como enviar um pull request:
 
-* **[Faça um fork do repositório](https://guides.github.com/activities/forking/)** e clone localmente. Conecte seu repositório local com o "upstream" adicionado-o como repositório remoto. Baixe as alterações do "upstream" com frequência para que você fique atualizado, quando enviar seu pull request, os conflitos de mesclagem serão menos prováveis. (Veja instruções mais detalhadas [aqui](https://help.github.com/articles/syncing-a-fork/).)
+* **[Faça um fork do repositório](https://guides.github.com/activities/forking/)** e clone localmente. Conecte seu repositório local com o "upstream" adicionado-o como repositório remoto. Baixe as alterações do "upstream" com frequência para que você fique atualizado, quando enviar seu pull request, os conflitos de mesclagem serão menos prováveis. (Veja instruções mais detalhadas [aqui](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Crie um branch](https://guides.github.com/introduction/flow/)** para suas edições.
 * **Referencie qualquer issue relevante** ou documentação de suporte em seu PR (por exemplo, "Closes #37.")
 * **Inclua imagens do antes e depois** se suas mudanças incluírem diferenças no HTML/CSS. Copie e cole as imagens na mensagem do seu pull request.
diff --git a/_articles/pt/leadership-and-governance.md b/_articles/pt/leadership-and-governance.md
index 31f20d496bb..e417afe5ebc 100644
--- a/_articles/pt/leadership-and-governance.md
+++ b/_articles/pt/leadership-and-governance.md
@@ -73,7 +73,7 @@ Uma vez que você tenha estabelecido papéis de liderança, não esqueça de doc
 
 Ferramentas como [Vossibility](https://github.com/icecrime/vossibility-stack) podem ajudar você a rastrear publicamente quem está (ou não) fazendo contribuições para o projeto. A documentação dessas informações evita a percepção da comunidade de que os mantenedores são um grupo que toma suas decisões de maneira privada.
 
-Por fim, se seu projeto está no GitHub, considere movê-lo de sua conta pessoal para uma Organização e adicionar ao menos um admin de backup. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) torna mais fácil de gerenciar permissões e múltiplos repositórios e protege o legado de seu projeto por meio de [propriedade compartilhada](../building-community/#compartilhe-a-responsabilidade-pelo-seu-projeto).
+Por fim, se seu projeto está no GitHub, considere movê-lo de sua conta pessoal para uma Organização e adicionar ao menos um admin de backup. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) torna mais fácil de gerenciar permissões e múltiplos repositórios e protege o legado de seu projeto por meio de [propriedade compartilhada](../building-community/#compartilhe-a-responsabilidade-pelo-seu-projeto).
 
 ## Quando eu devo dar acesso de commit a alguém?
 
@@ -81,7 +81,7 @@ Algumas pessoas pensam que você deve dar acesso de commit para todo mundo que f
 
 Por outro lado, especialmente para projetos maiores e mais complexos, você pode querer dar acesso de commit apenas para pessoas que demonstraram compromisso. Não há um jeito certo de fazer isso - faça o que te deixa mais confortável!
 
-Se seu projeto está no GitHub, você pode usar os [branches protegidos](https://help.github.com/articles/about-protected-branches/) para gerenciar quem e sob quais circustâncias, pode efetuar um push em um branch particular.
+Se seu projeto está no GitHub, você pode usar os [branches protegidos](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) para gerenciar quem e sob quais circustâncias, pode efetuar um push em um branch particular.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index 67f552d5255..79d33c30d7e 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -28,7 +28,7 @@ Finalmente, seu projeto pode ter dependências que tenham licença ou cuja licen
 
 ## Os projetos públicos do GitHub são open source?
 
-Quando você [cria um novo projeto](https://help.github.com/articles/creating-a-new-repository/) no GitHub, você tem a opção de criar um repositório **privado** ou **público**.
+Quando você [cria um novo projeto](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) no GitHub, você tem a opção de criar um repositório **privado** ou **público**.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -43,7 +43,7 @@ Você pode copiar e colar uma licença existente diretamente no seu projeto.
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), e [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) são as licenças open source mais populares, mas há outras opções disponíveis. Você pode encontrar o texto completo destas licenças e instruções de como usá-las, em [choosealicense.com](https://choosealicense.com/).
 
-Quando você criar um novo projeto no GitHub, será [dada a opção de adição de uma licença](https://help.github.com/articles/open-source-licensing/).
+Quando você criar um novo projeto no GitHub, será [dada a opção de adição de uma licença](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -89,7 +89,7 @@ Como alternativa, você pode fazer com que os colaboradores concordem com antece
 
 ## Meu projeto precisa de um contrato de contribuição adicional?
 
-Provavelmente não. Para a grande maioria dos projetos open source, uma licença open source serve implicitamente como a licença de entrada (de contribuidores) e de saída (para outros contribuidores e usuários). Se o seu projeto estiver no GitHub, os Termos de Serviço do GitHub tratam "entrada=saída" como o [padrão explícito](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Provavelmente não. Para a grande maioria dos projetos open source, uma licença open source serve implicitamente como a licença de entrada (de contribuidores) e de saída (para outros contribuidores e usuários). Se o seu projeto estiver no GitHub, os Termos de Serviço do GitHub tratam "entrada=saída" como o [padrão explícito](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Um contrato de contribuidor adicional - geralmente chamado de Contrato de Licença de Contribuidor (CLA) -- pode criar trabalho administrativo para os mantenedores do projeto. Quanto trabalho um contrato adiciona depende do projeto e da implementação. Um acordo simples pode exigir que os contribuidores confirmem, com um clique, que têm os direitos necessários para contribuir com a licença open source do projeto. Um acordo mais complicado pode exigir revisão legal e aprovação dos empregadores dos colaboradores.
 
diff --git a/_articles/pt/metrics.md b/_articles/pt/metrics.md
index f39eeea472f..573d8236eef 100644
--- a/_articles/pt/metrics.md
+++ b/_articles/pt/metrics.md
@@ -37,7 +37,7 @@ Antes das pessoas poderem contribuir para com seu projeto, elas precisam saber q
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Se seu projeto esta hospedado no GitHub, [você pode ver](https://help.github.com/articles/about-repository-graphs/#traffic) como as pessoas navegam no seu projeto e de onde elas vêm. Na página do seu projeto, clique "Insights" e então em "Traffic". Nesta página, você pode ver:
+Se seu projeto esta hospedado no GitHub, [você pode ver](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) como as pessoas navegam no seu projeto e de onde elas vêm. Na página do seu projeto, clique "Insights" e então em "Traffic". Nesta página, você pode ver:
 
 * **Total de visualizações da página:** Informa quantas vezes seu projeto foi visualizado
 
@@ -47,7 +47,7 @@ Se seu projeto esta hospedado no GitHub, [você pode ver](https://help.github.co
 
 * **Conteudo popular:** Informa a você onde os visitantes vão em seu projeto, a exibição mostra o número de visualizações por página e quantidade de visitantes.
 
-As [GitHub stars](https://help.github.com/articles/about-stars/) também podem ajudar a fornecer uma medida básica de popularidade. Embora as GitHub stars não estejam necessariamente relacionadas a downloads e uso, elas podem dizer quantas pessoas estão percebendo seu trabalho.
+As [GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) também podem ajudar a fornecer uma medida básica de popularidade. Embora as GitHub stars não estejam necessariamente relacionadas a downloads e uso, elas podem dizer quantas pessoas estão percebendo seu trabalho.
 
 Talvez você também queira [rastrear a descoberta apartir de lugares específicos](https://opensource.com/business/16/6/pirate-metrics): por exemplo, Google PageRank, tráfego de referência do site do seu projeto ou referências de outros projetos ou sites open source.
 
diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index 526ae4a0d15..fda32c0894b 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -113,9 +113,9 @@ De um modo geral, você deve tornar o seu projeto open source quando se sentir c
 
 Independente do estágio em que você decida tornar o seu projeto open source, todo projeto deve incluir as seguintes documentações:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 Como um mantenedor, esses componentes irão ajudá-lo a comunicar suas expectativas, administrar contribuições, e proteger o direito legal de todos (inclusive o seu). Eles aumentam suas chances de ter uma experência positiva significativamente.
@@ -189,7 +189,7 @@ Ao longo do tempo, você pode adicionar outras questões frequentemente respondi
 
 Para mais ajuda em como escrever seu arquivo CONTRIBUTING, dê uma olhada no [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) de @nayafia ou o ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) do @mozilla.
 
-Crie um link para seu arquivo CONTRIBUTING a partir do seu README, de modo que mais pessoas possam vê-lo. Se você [colocar seu arquivo CONTRIBUTING no repositório do seu projeto](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), o GitHub irá automaticamente "linkar" para o seu arquivo quando um contribuidor criar uma issue ou abrir um pull request.
+Crie um link para seu arquivo CONTRIBUTING a partir do seu README, de modo que mais pessoas possam vê-lo. Se você [colocar seu arquivo CONTRIBUTING no repositório do seu projeto](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), o GitHub irá automaticamente "linkar" para o seu arquivo quando um contribuidor criar uma issue ou abrir um pull request.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -262,7 +262,7 @@ Não é necessário escrever um guia de estilo para o seu projeto quando você e
 
 ## Seu checklist pré-lançamento
 
-Pronto para tornar o seu projeto open source? Aqui está uma checklist para ajudar. Marcou todas as caixas? Você está pronto! [Clique em "publish"](https://help.github.com/articles/making-a-private-repository-public/) e dê um tapinha em suas costas.
+Pronto para tornar o seu projeto open source? Aqui está uma checklist para ajudar. Marcou todas as caixas? Você está pronto! [Clique em "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) e dê um tapinha em suas costas.
 
 **Documentação**
 
diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md
index a761b6dc5b3..3088b078fde 100644
--- a/_articles/ro/best-practices.md
+++ b/_articles/ro/best-practices.md
@@ -254,7 +254,7 @@ Una dintre cele mai importante căi prin care poți să-ți automatizezi proiect
 
 Testele îi fac pe contributori să se simtă încrezători că ei nu strică nimic. Ele de asemenea îți ușurează analizarea și acceptarea rapidă a contribuțiilor. Cu cât ești mai receptiv, cu atât comunitatea ta poate fi mai angajată.
 
-Configurează teste automate care vor rula pe toate contribuțiile ce vin, și asigură-te că testele pot fi ușor rulate local de contributori. Cere ca toate contribuțiile să treacă testele tale înainte de a putea fi trimise. Vei ajuta la stabilirea unui standard minim de calitate pentru toate trimiterile. [Cererile de verificare de stare](https://help.github.com/articles/about-required-status-checks/) pe GitHub pot asigura că nicio schimbare nu este îmbinată fără să treacă testele tale.
+Configurează teste automate care vor rula pe toate contribuțiile ce vin, și asigură-te că testele pot fi ușor rulate local de contributori. Cere ca toate contribuțiile să treacă testele tale înainte de a putea fi trimise. Vei ajuta la stabilirea unui standard minim de calitate pentru toate trimiterile. [Cererile de verificare de stare](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) pe GitHub pot asigura că nicio schimbare nu este îmbinată fără să treacă testele tale.
 
 Dacă adaugi teste, asigură-te că explici cum funcționează în fișierul tău CONTRIBUTING.
 
diff --git a/_articles/ro/building-community.md b/_articles/ro/building-community.md
index 68b61861dd8..657f2223b2b 100644
--- a/_articles/ro/building-community.md
+++ b/_articles/ro/building-community.md
@@ -198,7 +198,7 @@ Vezi dacă poți găsi moduri de a împărți proprietatea cu comunitatea ta câ
 
 * **Dă tuturor contributorilor accesul pentru a face commit-uri** @felixge a găsit că aceasta a făcut oamenii [mai încântați să-și finiseze patch-urile](https://felixge.de/2013/03/11/the-pull-request-hack.html), și el chiar a găsit noi întreținători pentru proiecte la care n-a lucrat de ceva timp.
 
-* Dacă proiectul tău este pe GitHub, **mută-ți proiectul din contul tău personal într-o [Organizație](https://help.github.com/articles/creating-a-new-organization-account/)** și adaugă cel puțin un administrator de rezervă. Organizațiile fac mai ușor să lucrezi pe proiecte cu colaboratori externi.
+* Dacă proiectul tău este pe GitHub, **mută-ți proiectul din contul tău personal într-o [Organizație](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** și adaugă cel puțin un administrator de rezervă. Organizațiile fac mai ușor să lucrezi pe proiecte cu colaboratori externi.
 
 Realitatea este că [cele mai multe proiecte au doar](https://peerj.com/preprints/1233/) unul sau doi întreținători care fac cea mai multă muncă. Cu cât mai mare este proiectul tău, și mai mare comunitatea ta, cu atât mai ușor este să găsești ajutor.
 
diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md
index 05cc87ef994..24c0d6785a6 100644
--- a/_articles/ro/how-to-contribute.md
+++ b/_articles/ro/how-to-contribute.md
@@ -477,7 +477,7 @@ Dacă nu-ți poți găsi ideea altundeva, ești pregătit să faci o mutare. Dac
 
 Înainte de a deschide o problemă sau o cerere de pull, verifică documentația de contribuire a proiectului (de obicei un fișier numit CONTRIBUTING, sau în README), pentru a vedea dacă trebuie să incluzi ceva specific. De exemplu, ei îți pot cere să urmezi un șablon, sau să îți ceară să folosești teste.
 
-Dacă dorești să faci o contribuție substanțială, deschide o problemă și întreabă înainte de a lucra pe ea. Este de ajutor să urmăriți proiectul un timp (pe GitHub, [poți da clic pe "Watch"](https://help.github.com/articles/watching-repositories/) pentru a fi anunțat de toate conversațiile), și să începi să cunoști membrii comunității, înainte de a face muncă ce ar putea să nu fie acceptată.
+Dacă dorești să faci o contribuție substanțială, deschide o problemă și întreabă înainte de a lucra pe ea. Este de ajutor să urmăriți proiectul un timp (pe GitHub, [poți da clic pe "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) pentru a fi anunțat de toate conversațiile), și să începi să cunoști membrii comunității, înainte de a face muncă ce ar putea să nu fie acceptată.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -519,7 +519,7 @@ O cerere de pull nu trebuie să reprezinte muncă finalizată. Este de obicei ma
 
 Dacă proiectul este pe GitHub, iată cum trimiți o cerere de pull:
 
-* **[Bifurcă depozitul](https://guides.github.com/activities/forking/)** și clonează-l local. Conectează depozitul local la depozitul „upstream” original prin adăugarea lui ca un remote. Trage înăuntru schimbările din „upstream” des pentru a fii la curent astfel încât când îți trimiți cererea de pull, conflictele de îmbinare vor fi mai puțin probabile. (Vezi instrucțiuni mai detaliate [aici](https://help.github.com/articles/syncing-a-fork/).)
+* **[Bifurcă depozitul](https://guides.github.com/activities/forking/)** și clonează-l local. Conectează depozitul local la depozitul „upstream” original prin adăugarea lui ca un remote. Trage înăuntru schimbările din „upstream” des pentru a fii la curent astfel încât când îți trimiți cererea de pull, conflictele de îmbinare vor fi mai puțin probabile. (Vezi instrucțiuni mai detaliate [aici](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Creează o ramură](https://guides.github.com/introduction/flow/)** pentru editările tale.
 * **Referă oricare problemă relevantă** sau documentație justificativă în PR-ul tău (de exemplu, „Closes #37.”)
 * **Include capturi de ecran de dinainte și de după** dacă schimbările tale includ diferențe în HTML/CSS. Trage și lasă imaginile în corpul cererii tale de pull.
diff --git a/_articles/ro/leadership-and-governance.md b/_articles/ro/leadership-and-governance.md
index 49167855f64..103f343b801 100644
--- a/_articles/ro/leadership-and-governance.md
+++ b/_articles/ro/leadership-and-governance.md
@@ -94,7 +94,7 @@ Odată ce ai stabilit roluri de conducere, nu uita să documentezi modul în car
 
 Unelte cum ar fi [Vossibility](https://github.com/icecrime/vossibility-stack) pot să te ajute să urmărești în mod public cine face (sau nu) contribuții la proiect. Documentarea acestor informații evită percepția comunității că întreținătorii sunt o clică ce își ia deciziile în privat.
 
-În cele din urmă, dacă proiectul tău este pe GitHub, consideră mutarea proiectului tău din contul personal într-o organizație și adăugarea a cel puțin unui administrator de rezervă. [Organizațiile GitHub](https://help.github.com/articles/creating-a-new-organization-account/) ușurează gestionarea permisiunilor și multiplelor depozite și protejează moștenirea proiectului tău prin [proprietate comună](../building-community/#împarte-proprietatea-proiectului-tău).
+În cele din urmă, dacă proiectul tău este pe GitHub, consideră mutarea proiectului tău din contul personal într-o organizație și adăugarea a cel puțin unui administrator de rezervă. [Organizațiile GitHub](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) ușurează gestionarea permisiunilor și multiplelor depozite și protejează moștenirea proiectului tău prin [proprietate comună](../building-community/#împarte-proprietatea-proiectului-tău).
 
 ## Când ar trebui să dau cuiva acces de commit?
 
@@ -102,7 +102,7 @@ Unii oameni gândesc că ar trebui să dea acces de commit la oricine face o con
 
 Pe de altă parte, în special pentru proiectele mai mari, mai complexe, ai putea vrea să dai acces de commit doar oamenilor care și-au demonstrat angajamentul. Nu există o singură cale corectă de a face aceasta - fă ce te face cel mai confortabil!
 
-Dacă proiectul tău este pe GitHub, poți folosi [ramuri protejate](https://help.github.com/articles/about-protected-branches/) pentru a gestiona cine poate face push spre o anumită ramură, și în care circumstanțe.
+Dacă proiectul tău este pe GitHub, poți folosi [ramuri protejate](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) pentru a gestiona cine poate face push spre o anumită ramură, și în care circumstanțe.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index b4d5bed7e4b..917e8b44c1b 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -28,7 +28,7 @@ Dacă nu aplici o licență open source, oricine contribuie la proiectul tău de
 
 ## Sunt proiectele GitHub publice open source?
 
-Când tu [creezi un proiect nou](https://help.github.com/articles/creating-a-new-repository/) pe GitHub, ai opțiunea să faci depozitul **privat** sau **public**.
+Când tu [creezi un proiect nou](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) pe GitHub, ai opțiunea să faci depozitul **privat** sau **public**.
 
 ![Creează depozit](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Ai noroc, deoarece astăzi, licențele de sursă deschisă sunt standardizate ș
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), și [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sunt cele mai populare licențe open source, dar există alte opțiuni din care să alegi. Poți găsi textul întreg al acestor licențe, și instrucțiuni despre cum să le folosești, pe [choosealicense.com](https://choosealicense.com/).
 
-Când creezi un nou proiect pe GitHub, ți se va [cere să adaugi o licență](https://help.github.com/articles/open-source-licensing/).
+Când creezi un nou proiect pe GitHub, ți se va [cere să adaugi o licență](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -95,7 +95,7 @@ De exemplu, pe măsură ce proiectul tău crește el adaugă dependențe sau uti
 
 ## Proiectul meu are nevoie de o înțelegere cu contributorii în plus?
 
-Probabil că nu. Pentru marea majoritate a proiectelor open source, o licență open source implicit servește atât ca licență de intrare (de la contributori) cât și de ieșire (celorlalți contributori și utilizatori). Dacă proiectul tău este pe GitHub, Termenii serviciului GitHub fac „intrare = ieșire” [explicitul implicit](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Probabil că nu. Pentru marea majoritate a proiectelor open source, o licență open source implicit servește atât ca licență de intrare (de la contributori) cât și de ieșire (celorlalți contributori și utilizatori). Dacă proiectul tău este pe GitHub, Termenii serviciului GitHub fac „intrare = ieșire” [explicitul implicit](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Un acord de contributor în plus -- deseori numit un Contributor License Agreement (CLA) -- poate crea muncă administrativă pentru întreținătorii proiectului. Cât de multă muncă adaugă un acord depinde de proiect și de implementare. Un simplu acord ar putea necesita ca acei contributori să confirme, cu un clic, că ei au drepturile necesare să contribuie în baza licenței open source a proiectului. Un acord mai complicat ar putea necesita revizuire juridică și semnături de la angajatorii contributorilor.
 
diff --git a/_articles/ro/metrics.md b/_articles/ro/metrics.md
index 536645dc2c0..19a6d5a9856 100644
--- a/_articles/ro/metrics.md
+++ b/_articles/ro/metrics.md
@@ -39,7 +39,7 @@ Dacă _ești_ interesat în înțelegerea proiectului tău la un nivel mai profu
 
 ![Grafic de trafic](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Dacă proiectul tău este găzduit pe GitHub, [poți vizualiza](https://help.github.com/articles/about-repository-graphs/#traffic) câți oameni ajung la proiectul tău și de unde vin ei. Din pagina proiectului tău, fă clic pe „Insights”, apoi „Traffic”. Pe această pagină, poți vedea:
+Dacă proiectul tău este găzduit pe GitHub, [poți vizualiza](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) câți oameni ajung la proiectul tău și de unde vin ei. Din pagina proiectului tău, fă clic pe „Insights”, apoi „Traffic”. Pe această pagină, poți vedea:
 
 * **Vizualizări totale ale paginii:** Îți spune de câte ori a fost văzut proiectul tău
 
@@ -49,7 +49,7 @@ Dacă proiectul tău este găzduit pe GitHub, [poți vizualiza](https://help.git
 
 * **Conținut popular:** Îți spune unde merg vizitatorii în proiectul tău, defalcat în funcție de vizualizările de pagini și vizitatori unici.
 
-[Stelele GitHub](https://help.github.com/articles/about-stars/) pot, de asemenea, furniza o măsură de bază a popularității. În timp ce stelele GitHub nu sunt neapărat corelate cu descărcările și utilizarea, ele îți pot spune cât de mulți oameni îți iau la cunoștință munca.
+[Stelele GitHub](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) pot, de asemenea, furniza o măsură de bază a popularității. În timp ce stelele GitHub nu sunt neapărat corelate cu descărcările și utilizarea, ele îți pot spune cât de mulți oameni îți iau la cunoștință munca.
 
 Poate ai dori de asemenea să [urmărești abilitatea de a fi descoperit în locuri specifice](https://opensource.com/business/16/6/pirate-metrics): de exemplu, Google PageRank, trafic trimis din site-ul web al proiectului tău, sau trimiteri de la alte proiecte cu sursă deschisă sau site-uri web.
 
diff --git a/_articles/ro/starting-a-project.md b/_articles/ro/starting-a-project.md
index a2eb78ec48a..5eed05b1935 100644
--- a/_articles/ro/starting-a-project.md
+++ b/_articles/ro/starting-a-project.md
@@ -134,9 +134,9 @@ Nu există timpul perfect pentru a deschide sursa muncii tale. Poți deschide o
 
 Indiferent de stadiul în care decizi să deschizi sursa proiectului, oricare proiect ar trebui să includă următoarea documentație:
 
-* [Licența de sursă deschisă](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)
-* [Direcții de contribuție](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Licența de sursă deschisă](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Direcții de contribuție](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Codul de conduită](../code-of-conduct/)
 
 Ca și întreținător, aceste componente te vor ajuta să comunici așteptări, să gestionezi contribuții, și să protejezi drepturile legale ale tuturor (inclusiv ale tale). Ele cresc semnificativ șansele de a avea o experiență pozitivă.
@@ -219,7 +219,7 @@ Cu timpul, ai putea adăuga alte întrebări puse des în fișierul tău CONTRIB
 
 Pentru mai mult ajutor cu scrierea fișierului tău CONTRIBUTING, aruncă o privire la [șablonul de ghid de contribuire](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) al @nayafia sau [„How to Build a CONTRIBUTING.md”](https://mozillascience.github.io/working-open-workshop/contributing/) al @mozilla.
 
-Leagă către fișierul tău CONTRIBUTING din README-ul tău, astfel încât mai mulți oameni îl văd. Dacă [amplasezi fișierul tău CONTRIBUTING în depozitul proiectului tău](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub va lega automat către fișierul tău când un contributor creează o problemă sau deschide o cerere de pull.
+Leagă către fișierul tău CONTRIBUTING din README-ul tău, astfel încât mai mulți oameni îl văd. Dacă [amplasezi fișierul tău CONTRIBUTING în depozitul proiectului tău](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub va lega automat către fișierul tău când un contributor creează o problemă sau deschide o cerere de pull.
 
 ![Direcții de contribuire](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -306,7 +306,7 @@ Nu este necesar să scrii un ghid de stil pentru proiectul tău la început, și
 
 ## Lista ta de verificări înainte de lansare
 
-Ești pregătit să deschizi sursa proiectului tău? Iată o listă de verificare pentru a te ajuta. Bifezi toate cutiile? Ești gata să pornești! [Dă clic pe „publish”](https://help.github.com/articles/making-a-private-repository-public/) și mângâie-te pe spate.
+Ești pregătit să deschizi sursa proiectului tău? Iată o listă de verificare pentru a te ajuta. Bifezi toate cutiile? Ești gata să pornești! [Dă clic pe „publish”](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) și mângâie-te pe spate.
 
 **Documentație**
 
diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index 111bf483312..372f5b95d3f 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -165,7 +165,7 @@ related:
 
 Если вы ищете, кто мог бы помочь, начните с расспросов.
 
-Один из способов привлечь новых контрибьюторов — [добавить ярлык на те ишью, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub будет отображать их в различных местах сайта, делая тем самым их более заметными.
+Один из способов привлечь новых контрибьюторов — [добавить ярлык на те ишью, которые достаточно просты для начинающих](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). Затем GitHub будет отображать их в различных местах сайта, делая тем самым их более заметными.
 
 Когда вы видите, что новые контрибьюторы неоднократно вносят свой вклад, признайте их работу, предложив больше ответственности. Задокументируйте, как люди могут занять руководящие роли, если захотят.
 
@@ -215,7 +215,7 @@ related:
 
 Тесты помогают участникам чувствовать себя уверенно в том, что в результате новых изменений ничего не было сломано. Они также облегчают рассмотрение и принятие вкладов. Чем активнее вы будете реагировать, тем более заинтересованным может быть ваше сообщество.
 
-Настройте автотесты, которые будут запускаться на всех входящих вкладов, и убедитесь, что они могут быть выполнены контрибьюторами локально. Требуйте, чтобы весь код от контрибьюторов проходил тесты, до того, как они отправлять сам вклад. Вы поможете установить минимальный стандарт качества для всех отправляемых вкладов. [Обязательные проверки статуса](https://help.github.com/articles/about-required-status-checks/) на GitHub помогут проследить за тем, что никакие изменения не будут объединены без прохождения тестов.
+Настройте автотесты, которые будут запускаться на всех входящих вкладов, и убедитесь, что они могут быть выполнены контрибьюторами локально. Требуйте, чтобы весь код от контрибьюторов проходил тесты, до того, как они отправлять сам вклад. Вы поможете установить минимальный стандарт качества для всех отправляемых вкладов. [Обязательные проверки статуса](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) на GitHub помогут проследить за тем, что никакие изменения не будут объединены без прохождения тестов.
 
 Если вы добавляете тесты, обязательно объясните, как они работают в файле CONTRIBUTING.
 
diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index d36599b4600..39647eee40b 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -28,7 +28,7 @@ related:
 
 * **Облегчите использование вашего проекта для любого желающего.** [Дружественное README](../starting-a-project/#написание-readme) и понятные примеры кода помогут любому, кто заинтересуется вашим проектом, начать работу.
 * **Объясните, как участвовать**, используя [руководство для участников](../starting-a-project/#написание-руководства-для-участников) и оперативно отвечая на вопросы (issues).
-* **Хорошие первые вопросы (issues)**: чтобы помочь новым участникам начать работу, явно рассмотрите [ярлыки вопросов, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub выведет эти вопросы в различных местах платформы, увеличивая полезный вклад и уменьшая трение пользователей, решающих проблемы, которые слишком сложны для их уровня.
+* **Хорошие первые вопросы (issues)**: чтобы помочь новым участникам начать работу, явно рассмотрите [ярлыки вопросов, которые достаточно просты для начинающих](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). Затем GitHub выведет эти вопросы в различных местах платформы, увеличивая полезный вклад и уменьшая трение пользователей, решающих проблемы, которые слишком сложны для их уровня.
 
 [Обзор открытого исходного кода GitHub за 2017 год](http://opensourcesurvey.org/2017/) показал, что неполная или запутанная документация является самой большой проблемой для пользователей открытого исходного кода. Хорошая документация побуждает людей взаимодействовать с вашим проектом. В конце концов, кто-то откроет вопрос или пул-реквест. Используйте эти взаимодействия как возможности для продвижения их по воронке.
 
@@ -167,7 +167,7 @@ related:
 
 * **Предоставьте каждому участнику доступ к коммитам.** @felixge обнаружил, что это заставило людей [с большим энтузиазмом оттачивать свои патчи](https://felixge.de/2013/03/11/the-pull-request-hack.html), и он даже нашел новых сопровождающих для проектов, над которыми давно не работал.
 
-* Если ваш проект размещен на GitHub, **переместите его из своей личной учетной записи в [Организацию](https://help.github.com/articles/creating-a-new-organization-account/)** и добавьте хотя бы одного резервного администратора. Организации упрощают работу над проектами с внешними соавторами.
+* Если ваш проект размещен на GitHub, **переместите его из своей личной учетной записи в [Организацию](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** и добавьте хотя бы одного резервного администратора. Организации упрощают работу над проектами с внешними соавторами.
 
 Реальность такова, что [в большинстве проектов есть](https://peerj.com/preprints/1233/) один или два сопровождающих, которые делают большую часть работы. Чем крупнее ваш проект и чем больше ваше сообщество, тем легче найти помощь.
 
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index dbfdb2a69ae..85c68e78168 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -439,7 +439,7 @@ related:
 
 Прежде чем открывать ишью или пул-реквест, ознакомьтесь с руководством по участию (обычно ему посвящен отдельный файл с именем CONTRIBUTING или соответствующий раздел в файле README), чтобы сделать всё правильно. Например, вас могут попросить представить информацию согласно шаблону или потребовать, чтобы вы написали тесты.
 
-Если вы планируете сделать большое изменение, перед этим лучше откройте ишью. Полезно некоторое время понаблюдать за проектом (на GitHub [для этого можно кликнуть по кнопке «Watch»](https://help.github.com/articles/watching-repositories/), чтобы получать уведомления обо всех активностях), а также познакомиться с некоторыми участниками сообщества.
+Если вы планируете сделать большое изменение, перед этим лучше откройте ишью. Полезно некоторое время понаблюдать за проектом (на GitHub [для этого можно кликнуть по кнопке «Watch»](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications), чтобы получать уведомления обо всех активностях), а также познакомиться с некоторыми участниками сообщества.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -474,7 +474,7 @@ related:
 
 Если проект находится на GitHub, выполните следующие шаги, чтобы создать пул-реквест:
 
-* **[Форкните репозиторий](https://guides.github.com/activities/forking/)** и склонируйте его к себе локально. Затем в этом локальном репозитории добавьте оригинальный (upstream) репозиторий. Почаще загружайте изменения из исходного репозитория, чтобы ваш локальный репозиторий оставался в актуальном состоянии, — это снизит вероятность возникновения конфликтов при создании пул-реквеста. (См. более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).)
+* **[Форкните репозиторий](https://guides.github.com/activities/forking/)** и склонируйте его к себе локально. Затем в этом локальном репозитории добавьте оригинальный (upstream) репозиторий. Почаще загружайте изменения из исходного репозитория, чтобы ваш локальный репозиторий оставался в актуальном состоянии, — это снизит вероятность возникновения конфликтов при создании пул-реквеста. (См. более подробные инструкции [здесь](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Создайте ветку](https://guides.github.com/introduction/flow/)** для ваших правок.
 * **Ссылайтесь на любые относящиеся к делу ишью** или подтверждающую документацию в своем PR (например, «Closes #37»).
 * **Добавьте скриншоты до и после**, если ваши изменения затрагивают файлы HTML/CSS. Перетащите изображения в текстовую область пул-реквеста.
diff --git a/_articles/ru/leadership-and-governance.md b/_articles/ru/leadership-and-governance.md
index 102a855a2f9..8ea8b51ae06 100644
--- a/_articles/ru/leadership-and-governance.md
+++ b/_articles/ru/leadership-and-governance.md
@@ -67,7 +67,7 @@ related:
 
 Такие инструменты, как [Vossibility](https://github.com/icecrime/vossibility-stack), могут помочь вам публично отслеживать, кто вносит (или не вносит) вклад в проект. Документирование этой информации позволяет избежать восприятия сообществом того, что сопровождающие - это клика, которая принимает решения втайне от всех.
 
-Наконец, если ваш проект находится на GitHub, подумайте о переносе проекта из личного аккаунта в Организацию и добавлении хотя бы одного резервного администратора. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) облегчают управление разрешениями и несколькими репозиториями и защищают наследие вашего проекта благодаря [общему владению](../building-community/#совместное-владение-вашим-проектом).
+Наконец, если ваш проект находится на GitHub, подумайте о переносе проекта из личного аккаунта в Организацию и добавлении хотя бы одного резервного администратора. [GitHub Organizations](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) облегчают управление разрешениями и несколькими репозиториями и защищают наследие вашего проекта благодаря [общему владению](../building-community/#совместное-владение-вашим-проектом).
 
 ## Когда я должен предоставить кому-то доступ на правки (commit)?
 
@@ -75,7 +75,7 @@ related:
 
 С другой стороны, особенно для больших, более сложных проектов, вы можете захотеть предоставить commit доступ только тем людям, которые продемонстрировали свою приверженность. Не существует единственно правильного способа - делайте то, что вам удобнее всего!
 
-Если ваш проект находится на GitHub, вы можете использовать [защищенные ветки](https://help.github.com/articles/about-protected-branches/), чтобы управлять тем, кто и при каких обстоятельствах может отправлять правки (push) в определенную ветку.
+Если ваш проект находится на GitHub, вы можете использовать [защищенные ветки](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches), чтобы управлять тем, кто и при каких обстоятельствах может отправлять правки (push) в определенную ветку.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index 07bea565344..acc7c986d7b 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -28,11 +28,11 @@ related:
 
 ## Открыты ли общедоступные проекты GitHub?
 
-Когда вы [создаете новый проект](https://help.github.com/articles/creating-a-new-repository/) на GitHub, у вас есть возможность сделать репозиторий **приватным** (частным) или **публичным** (общедоступным).
+Когда вы [создаете новый проект](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) на GitHub, у вас есть возможность сделать репозиторий **приватным** (частным) или **публичным** (общедоступным).
 
 ![Создать репозиторий](/assets/images/legal/repo-create-name.png)
 
-**Сделать ваш проект GitHub публичным — это не то же самое, что лицензировать ваш проект**. На общедоступные проекты распространяются [Условия использования GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-owner-of-content-right-to-post-and-license-grants), которые позволяют другим просматривать и делать ответвление (fork) вашего проекта. Но в остальном ваша работа не имеет разрешений.
+**Сделать ваш проект GitHub публичным — это не то же самое, что лицензировать ваш проект**. На общедоступные проекты распространяются [Условия использования GitHub](https://docs.github.com/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), которые позволяют другим просматривать и делать ответвление (fork) вашего проекта. Но в остальном ваша работа не имеет разрешений.
 
 Если вы хотите, чтобы другие могли использовать, распространять, изменять или вносить свой вклад в ваш проект, вам необходимо включить лицензию открытого исходного кода. Например, кто-то не может законно использовать какую-либо часть вашего проекта GitHub в своем коде, даже если он общедоступен, если вы явно не дадите ему на это право.
 
@@ -42,7 +42,7 @@ related:
 
 [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/).
+Когда вы создаете новый проект на GitHub, вас [попросят добавить лицензию](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ related:
 
 ## Требуется ли для моего проекта дополнительное соглашение с участниками?
 
-Возможно нет. Для подавляющего большинства проектов лицензия для открытого исходного кода неявно служит как входящей (от участников), так и исходящей (для других участников и пользователей) лицензией. Если ваш проект размещен на GitHub, то Условия использования GitHub делают "inbound = outbound" [явным значением по умолчанию](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Возможно нет. Для подавляющего большинства проектов лицензия для открытого исходного кода неявно служит как входящей (от участников), так и исходящей (для других участников и пользователей) лицензией. Если ваш проект размещен на GitHub, то Условия использования GitHub делают "inbound = outbound" [явным значением по умолчанию](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Дополнительное соглашение с участником, часто называемое лицензионным соглашением участника (CLA), может создавать административную работу для сопровождающих проект. Сколько работы добавляет соглашение, зависит от проекта и реализации. Простое соглашение может требовать, чтобы участники подтвердили одним щелчком мыши, что у них есть права, необходимые для внесения вклада в соответствии с лицензией проекта с открытым исходным кодом. Более сложное соглашение может потребовать юридической проверки и подписи со стороны работодателей участников.
 
diff --git a/_articles/ru/metrics.md b/_articles/ru/metrics.md
index 63f5b9d5743..a73d6b51092 100644
--- a/_articles/ru/metrics.md
+++ b/_articles/ru/metrics.md
@@ -37,7 +37,7 @@ related:
 
 ![График трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Если ваш проект размещён на GitHub, [вы можете посмотреть](https://help.github.com/articles/about-repository-graphs/#traffic), сколько людей попадают в ваш проект и откуда они приходят. На странице вашего проекта нажмите **Insights**, затем **Traffic**. На этой странице вы можете увидеть:
+Если ваш проект размещён на GitHub, [вы можете посмотреть](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository), сколько людей попадают в ваш проект и откуда они приходят. На странице вашего проекта нажмите **Insights**, затем **Traffic**. На этой странице вы можете увидеть:
 
 * **Общее количество просмотров страниц:** показывает, сколько раз был просмотрен ваш проект.
 
@@ -47,7 +47,7 @@ related:
 
 * **Популярный контент:** рассказывает о том, куда заходят посетители вашего проекта, в разбивке по просмотрам страниц и уникальным посетителям.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) также может помочь определить базовый показатель популярности. Хотя звезды GitHub не обязательно коррелируют с загрузками и использованием, они могут сказать вам, сколько людей обращают внимание на вашу работу.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) также может помочь определить базовый показатель популярности. Хотя звезды GitHub не обязательно коррелируют с загрузками и использованием, они могут сказать вам, сколько людей обращают внимание на вашу работу.
 
 Вы также можете захотеть [отслеживать открываемость в определенных местах](https://opensource.com/business/16/6/pirate-metrics): например, Google PageRank, реферальный трафик с сайта вашего проекта или рефералы с других проектов с открытым исходным кодом или сайтов.
 
diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md
index 1bde48b48e3..fe083c44a1f 100644
--- a/_articles/ru/starting-a-project.md
+++ b/_articles/ru/starting-a-project.md
@@ -106,9 +106,9 @@ _Свободное ПО_ относится к тем же проектам, ч
 
 В каждом проекте вне зависимости от стадии, на которой вы решили открыть исходники, должна быть следующая документация:
 
-* [Опенсорс-лицензию](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)
-* [Руководство для участников](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Опенсорс-лицензию](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Руководство для участников](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Нормы поведения](../code-of-conduct/)
 
 Эти файлы помогут вам донести ожидания, определить процесс по участию, и защитить законные права всех, включая вас самих. Всё это значительно увеличивает шансы, что всё пойдёт хорошо.
@@ -182,7 +182,7 @@ _Свободное ПО_ относится к тем же проектам, ч
 
 Чтобы вам было проще написать файл CONTRIBUTING, ознакомьтесь с [шаблоном руководства по сотрудничеству](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) от @nayafia или прочтите ["Как создать файл CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) от @mozilla.
 
-Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы [разместите файл CONTRIBUTING.md в корне вашего проекта](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), то GitHub автоматически предложит ознакомиться с ним когда кто-то открывает ишью или отправляет пул-реквест.
+Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы [разместите файл CONTRIBUTING.md в корне вашего проекта](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), то GitHub автоматически предложит ознакомиться с ним когда кто-то открывает ишью или отправляет пул-реквест.
 
 ![Руководство по сотрудничеству](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ _Свободное ПО_ относится к тем же проектам, ч
 
 ## Чеклист перед запуском
 
-Вы готовы открыть свой проект? Вот вам проверочный лист в помощь. Когда отметите все пункты, [откройте ваш проект](https://help.github.com/articles/making-a-private-repository-public/) и похвалите себя.
+Вы готовы открыть свой проект? Вот вам проверочный лист в помощь. Когда отметите все пункты, [откройте ваш проект](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) и похвалите себя.
 
 **Документация**
 
diff --git a/_articles/sa/best-practices.md b/_articles/sa/best-practices.md
index 725c0304b3f..db45e5a0d8e 100644
--- a/_articles/sa/best-practices.md
+++ b/_articles/sa/best-practices.md
@@ -163,7 +163,7 @@ related:
 
 अन्यैः सहाय्यं अपेक्ष्यते चेत्, प्रथमं पृच्छतु।
 
-नूतन योगदानकर्तृ प्रोत्साहनाय, [सरल समस्याः चिह्नितान्](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) कुर्वीत। GitHub प्लेटफॉर्मे दृश्यतां वर्धयति।
+नूतन योगदानकर्तृ प्रोत्साहनाय, [सरल समस्याः चिह्नितान्](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels) कुर्वीत। GitHub प्लेटफॉर्मे दृश्यतां वर्धयति।
 
 नूतन योगदानकर्तृ निरन्तर योगदानं कुर्वन्, तेषां कार्यं मानयतु। अन्यैः नेतृत्व भूमिकां प्राप्तुं मार्गदर्शनं लिखतु।  
 
diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index bea87469482..0a40fede3af 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -106,9 +106,9 @@ Generally speaking, you should open source your project when you feel comfortabl
 
 No matter which stage you decide to open source your project, every project should include the following documentation:
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience.
@@ -182,7 +182,7 @@ Over time, you might add other frequently asked questions to your CONTRIBUTING f
 
 For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
+Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -255,7 +255,7 @@ It isn't necessary to write a style guide for your project when you're just star
 
 ## Your pre-launch checklist
 
-Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back.
+Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) and pat yourself on the back.
 
 **Documentation**
 
diff --git a/_articles/sw/best-practices.md b/_articles/sw/best-practices.md
index 9f7edabfc72..f7cacf4c449 100644
--- a/_articles/sw/best-practices.md
+++ b/_articles/sw/best-practices.md
@@ -165,7 +165,7 @@ Huna haja ya kufanya kila kitu mwenyewe. Jamii ya mradi wako ipo kwa sababu! Hat
 
 Ikiwa unatafuta wengine kusaidia, anza kwa kuuliza.
 
-Njia moja ya kupata wachangiaji wapya ni wazi [kuweka lebo kwenye masuala ambayo ni rahisi vya kutosha kwa waanzilishi kushughulikia](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub kisha itawasilisha masuala haya katika maeneo mbalimbali kwenye jukwaa, kuongeza mwonekano wao.
+Njia moja ya kupata wachangiaji wapya ni wazi [kuweka lebo kwenye masuala ambayo ni rahisi vya kutosha kwa waanzilishi kushughulikia](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub kisha itawasilisha masuala haya katika maeneo mbalimbali kwenye jukwaa, kuongeza mwonekano wao.
 
 Unapowaona wachangiaji wapya wakifanya michango mara kwa mara, tambua kazi yao kwa kuwapea majukumu zaidi. Andika jinsi wengine wanaweza kukua katika nafasi za uongozi ikiwa wanataka.
 
@@ -215,7 +215,7 @@ Mojawapo ya njia muhimu zaidi unaweza kufanya mradi wako otomatiki ni kwa kuonge
 
 Majaribio huwasaidia wachangiaji kujiamini kuwa hawatavunja chochote. Pia hukurahisishia kukagua na kukubali michango haraka. Kadiri unavyokuwa msikivu zaidi, ndivyo jumuiya yako inavyoweza kuhusika zaidi.
 
-Weka majaribio ya kiotomatiki ambayo yataendeshwa kwa michango yote inayoingia, na uhakikishe kuwa majaribio yako yanaweza kufanyiwa "locally" na wachangiaji kwa urahisi. Inahitaji kwamba michango yote ya misimbo ipite majaribio yako kabla ya kuwasilishwa. Utasaidia kuweka kiwango cha chini kabisa cha ubora kwa mawasilisho yote. [Ukaguzi wa hali unaohitajika](https://help.github.com/articles/about-required-status-checks/) kwenye GitHub inaweza kusaidia kuhakikisha hakuna mabadiliko yanayounganishwa bila majaribio yako kupita.
+Weka majaribio ya kiotomatiki ambayo yataendeshwa kwa michango yote inayoingia, na uhakikishe kuwa majaribio yako yanaweza kufanyiwa "locally" na wachangiaji kwa urahisi. Inahitaji kwamba michango yote ya misimbo ipite majaribio yako kabla ya kuwasilishwa. Utasaidia kuweka kiwango cha chini kabisa cha ubora kwa mawasilisho yote. [Ukaguzi wa hali unaohitajika](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) kwenye GitHub inaweza kusaidia kuhakikisha hakuna mabadiliko yanayounganishwa bila majaribio yako kupita.
 
 Ukiongeza majaribio, hakikisha umeeleza jinsi yanavyofanya kazi katika faili yako ya KUCHANGIA.
 
diff --git a/_articles/sw/building-community.md b/_articles/sw/building-community.md
index c3500bfecc5..76f0921d88a 100644
--- a/_articles/sw/building-community.md
+++ b/_articles/sw/building-community.md
@@ -28,7 +28,7 @@ Anza na nyaraka zako:
 
 * **Fanya iwe rahisi kwa mtu kutumia mradi wako.** [README ya kirafiki](../starting-a-project/#kuandika-readme) na mifano wazi ya msimbo itafanya iwe rahisi kwa yeyote anayekuja kwenye mradi wako kuanza.
 * **Eleza wazi jinsi ya kuchangia**, ukitumia [faili yako ya CONTRIBUTING](../starting-a-project/#kuandika-miongozo-yako-ya-kuchangia) na kuweka masuala yako kuwa ya kisasa.
-* **Masuala mazuri ya kwanza**: Ili kuwasaidia wachangiaji wapya kuanza, fikiria wazi [kuyapachika masuala ambayo ni rahisi vya kutosha kwa waanzilishi kushughulikia](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub kisha itawasilisha masuala haya katika maeneo mbalimbali kwenye jukwaa, itakayoongeza michango yenye manufaa, na kupunguza vikwazo kutoka kwa watumiaji wanaoshughulikia masuala ambayo ni magumu sana kwa kiwango chao.
+* **Masuala mazuri ya kwanza**: Ili kuwasaidia wachangiaji wapya kuanza, fikiria wazi [kuyapachika masuala ambayo ni rahisi vya kutosha kwa waanzilishi kushughulikia](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub kisha itawasilisha masuala haya katika maeneo mbalimbali kwenye jukwaa, itakayoongeza michango yenye manufaa, na kupunguza vikwazo kutoka kwa watumiaji wanaoshughulikia masuala ambayo ni magumu sana kwa kiwango chao.
 
 [Utafiti wa Open Source wa GitHub wa 2017](http://opensourcesurvey.org/2017/) ulionyesha kuwa nyaraka zisizokamilika au zenye kuchanganya ni tatizo kubwa kwa watumiaji wa open source. Nyaraka nzuri zinawakaribisha watu kuingiliana na mradi wako. Hatimaye, mtu atafungua suala au ombi la kuvuta. Tumia mwingiliano haya kama fursa za kuwahamisha chini ya mchoro.
 
@@ -167,7 +167,7 @@ Angalia ikiwa unaweza kupata njia za kushiriki umiliki na jamii yako kadri iweze
 
 * **Wape kila mchango ruhusa ya kuingia.** @felixge alipata kuwa hii ilifanya watu [kuwa na shauku zaidi ya kusafisha patches zao](https://felixge.de/2013/03/11/the-pull-request-hack.html), na hata alipata watunzaji wapya kwa miradi ambayo hakuwa amefanya kazi nayo kwa muda.
 
-* Ikiwa mradi wako uko GitHub, **hamasisha mradi wako kutoka kwenye akaunti yako binafsi hadi [Shirika](https://help.github.com/articles/creating-a-new-organization-account/)** na ongeza angalau mtunzaji mmoja wa akiba. Mashirika yanafanya iwe rahisi kufanya kazi kwenye miradi na washirikishi wa nje.
+* Ikiwa mradi wako uko GitHub, **hamasisha mradi wako kutoka kwenye akaunti yako binafsi hadi [Shirika](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** na ongeza angalau mtunzaji mmoja wa akiba. Mashirika yanafanya iwe rahisi kufanya kazi kwenye miradi na washirikishi wa nje.
 
 Ukweli ni kwamba [miradi mingi ina](https://peerj.com/preprints/1233/) watunzaji mmoja au wawili tu wanaofanya kazi nyingi. Kadri mradi wako unavyokuwa, na kadri jamii yako inavyokuwa kubwa, ndivyo itakuwa rahisi kupata msaada.
 
diff --git a/_articles/sw/how-to-contribute.md b/_articles/sw/how-to-contribute.md
index 3dfbcb8aa7f..518c4b560eb 100644
--- a/_articles/sw/how-to-contribute.md
+++ b/_articles/sw/how-to-contribute.md
@@ -447,7 +447,7 @@ Ikiwa huwezi kupata wazo lako mahali pengine, uko tayari kuchukua hatua. Ikiwa m
 
 Kabla ya kufungua suala au ombi la kuvuta, angalia nyaraka za kuchangia za mradi (kawaida faili inayoitwa CONTRIBUTING, au katika README), ili kuona ikiwa unahitaji kujumuisha kitu chochote maalum. Kwa mfano, wanaweza kuomba ufuate templeti, au kuhitaji utumie majaribio(tests).
 
-Ikiwa unataka kutoa mchango mkubwa, fungua suala ili kuuliza kabla ya kufanya kazi juu yake. Ni muhimu kufuatilia mradi kwa muda (katika GitHub, [unaweza kubofya "Watch"](https://help.github.com/articles/watching-repositories/) ili kupokea taarifa za mazungumzo yote), na kujifunza kuhusu wanajamii, kabla ya kufanya kazi ambayo huenda isikubaliwe.
+Ikiwa unataka kutoa mchango mkubwa, fungua suala ili kuuliza kabla ya kufanya kazi juu yake. Ni muhimu kufuatilia mradi kwa muda (katika GitHub, [unaweza kubofya "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) ili kupokea taarifa za mazungumzo yote), na kujifunza kuhusu wanajamii, kabla ya kufanya kazi ambayo huenda isikubaliwe.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -482,7 +482,7 @@ Ombi la kuvuta halihitaji kuwakilisha kazi iliyokamilika. Kawaida ni bora kufung
 
 Ikiwa mradi uko kwenye GitHub, hapa kuna jinsi ya kuwasilisha ombi la kuvuta:
 
-* **["Fork" hazina](https://guides.github.com/activities/forking/)** kisha "clone" kwenye kompyuta yako. Unganisha yako ya ndani na hazina ya asili "upstream" kwa kuongeza kama rimoti. Vuruta mabadiliko kutoka "upstream" mara kwa mara ili uwe na mabadiliko mapya ili wakati unawasilisha ombi lako la kuvuta, migogoro ya kuungana itakuwa na uwezekano mdogo. (Tazama maelekezo ya kina [hapa](https://help.github.com/articles/syncing-a-fork/).)
+* **["Fork" hazina](https://guides.github.com/activities/forking/)** kisha "clone" kwenye kompyuta yako. Unganisha yako ya ndani na hazina ya asili "upstream" kwa kuongeza kama rimoti. Vuruta mabadiliko kutoka "upstream" mara kwa mara ili uwe na mabadiliko mapya ili wakati unawasilisha ombi lako la kuvuta, migogoro ya kuungana itakuwa na uwezekano mdogo. (Tazama maelekezo ya kina [hapa](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).)
 * **[Unda tawi](https://guides.github.com/introduction/flow/)** kwa ajili ya marekebisho yako.
 * **Rejelea masuala yoyote muhimu** au nyaraka za kuunga mkono katika PR yako (kwa mfano, "Inafunga #37.")
 * **Jumuisha picha za kabla na baada** ikiwa mabadiliko yako yanajumuisha tofauti katika HTML/CSS. Buruta na uachie picha hizo kwenye mwili wa ombi lako la kuvuta.
diff --git a/_articles/sw/leadership-and-governance.md b/_articles/sw/leadership-and-governance.md
index 48af3c4afe6..593b1167e3f 100644
--- a/_articles/sw/leadership-and-governance.md
+++ b/_articles/sw/leadership-and-governance.md
@@ -73,7 +73,7 @@ Mara tu umeshaunda majukumu ya uongozi, usisahau kuandika jinsi watu wanaweza ku
 
 Zana kama [Vossibility](https://github.com/icecrime/vossibility-stack) zinaweza kusaidia kufuatilia hadharani ni nani (au sio) anayechangia mradi. Kuandika habari hii husaidia kuepusha dhana ya jamii kwamba watunzaji ni kundi linalofanya maamuzi yake kwa siri.
 
-Hatimaye, ikiwa mradi wako uko kwenye GitHub, zingatia kuhamasisha mradi wako kutoka kwenye akaunti yako binafsi hadi Shirika na kuongeza angalau mtunzaji mmoja wa akiba. [Mashirika ya GitHub](https://help.github.com/articles/creating-a-new-organization-account/) yanafanya iwe rahisi kusimamia ruhusa na hazina nyingi na kulinda urithi wa mradi wako kupitia [umiliki wa pamoja](../building-community/#shiriki-umiliki-wa-mradi-wako).
+Hatimaye, ikiwa mradi wako uko kwenye GitHub, zingatia kuhamasisha mradi wako kutoka kwenye akaunti yako binafsi hadi Shirika na kuongeza angalau mtunzaji mmoja wa akiba. [Mashirika ya GitHub](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) yanafanya iwe rahisi kusimamia ruhusa na hazina nyingi na kulinda urithi wa mradi wako kupitia [umiliki wa pamoja](../building-community/#shiriki-umiliki-wa-mradi-wako).
 
 ## Ni lini ninapaswa kupatia mtu uwezo wa ufikiaji wa kuandika au kucommit?
 
@@ -81,7 +81,7 @@ Watu wengine wanafikiri unapaswa kumwambia kila mtu ambaye anachangia kuwa na uf
 
 Kwa upande mwingine, hasa kwa miradi mikubwa na ngumu zaidi, huenda unataka kuwapatia tu wale ambao wameonyesha kujitolea kwao. Hakuna njia moja sahihi ya kufanya hivyo - fanya kile kinachokufanya ujisikie vizuri!
 
-Ikiwa mradi wako uko kwenye GitHub, unaweza kutumia [protected branches](https://help.github.com/articles/about-protected-branches/) kusimamia ni nani anayeweza kusukuma kwenye tawi fulani, na chini ya hali gani.
+Ikiwa mradi wako uko kwenye GitHub, unaweza kutumia [protected branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) kusimamia ni nani anayeweza kusukuma kwenye tawi fulani, na chini ya hali gani.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/sw/legal.md b/_articles/sw/legal.md
index 245caf5fc1b..a1a54a926b6 100644
--- a/_articles/sw/legal.md
+++ b/_articles/sw/legal.md
@@ -28,7 +28,7 @@ Hatimaye, mradi wako unaweza kuwa na utegemezi wenye mahitaji ya leseni ambayo h
 
 ## Je, miradi ya umma ya GitHub ni open source?
 
-Unapounda [mradi mpya](https://help.github.com/articles/creating-a-new-repository/) kwenye GitHub, una chaguo la kufanya hifadhi kuwa **binafsi** au **ya umma**.
+Unapounda [mradi mpya](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) kwenye GitHub, una chaguo la kufanya hifadhi kuwa **binafsi** au **ya umma**.
 
 ![Unda hifadhi](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Uko bahati, kwa sababu leo, leseni za open source zimekuwa za kawaida na rahisi
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), na [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ni [leseni maarufu za open source](https://innovationgraph.github.com/global-metrics/licenses), lakini kuna chaguzi nyingine za kuchagua. Unaweza kupata maandiko kamili ya leseni hizi, na maelekezo ya jinsi ya kuzitumia, kwenye [choosealicense.com](https://choosealicense.com/).
 
-Unapounda mradi mpya kwenye GitHub, utaulizwa kuongeza leseni [hapa](https://help.github.com/articles/open-source-licensing/).
+Unapounda mradi mpya kwenye GitHub, utaulizwa kuongeza leseni [hapa](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -90,7 +90,7 @@ Vinginevyo, unaweza kuwa na wachangiaji wakikubali mabadiliko fulani ya leseni k
 
 ## Je, mradi wangu unahitaji makubaliano ya ziada ya wachangiaji?
 
-Huenda si. Kwa sehemu kubwa ya miradi ya open source, leseni ya open source inatumika kimya kama leseni ya kuingia (kutoka kwa wachangiaji) na leseni ya kutoka (kwa wachangiaji wengine na watumiaji). Ikiwa mradi wako uko kwenye GitHub, Masharti ya Huduma ya GitHub yanafanya "kuingia=kuondoka" kuwa [wa kutumika](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+Huenda si. Kwa sehemu kubwa ya miradi ya open source, leseni ya open source inatumika kimya kama leseni ya kuingia (kutoka kwa wachangiaji) na leseni ya kutoka (kwa wachangiaji wengine na watumiaji). Ikiwa mradi wako uko kwenye GitHub, Masharti ya Huduma ya GitHub yanafanya "kuingia=kuondoka" kuwa [wa kutumika](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 Makubaliano ya ziada ya wachangiaji -- mara nyingi huitwa Contributor License Agreement (CLA) -- yanaweza kuunda kazi za kiutawala kwa watunzaji wa mradi. Kiasi gani kazi makubaliano yanaongeza inategemea mradi na utekelezaji. Makubaliano rahisi yanaweza kuhitaji wachangiaji kuthibitisha, kwa kubonyeza, kwamba wana haki zinazohitajika kuchangia chini ya leseni ya open source ya mradi. Makubaliano magumu zaidi yanaweza kuhitaji ukaguzi wa kisheria na idhini kutoka kwa waajiri wa wachangiaji.
 
diff --git a/_articles/sw/metrics.md b/_articles/sw/metrics.md
index 5d56dc15f7c..29bd4bbbefe 100644
--- a/_articles/sw/metrics.md
+++ b/_articles/sw/metrics.md
@@ -37,7 +37,7 @@ Kabla ya mtu yeyote kutumia au kuchangia mradi wako, wanahitaji kujua kuwa upo.
 
 ![Grafu ya trafiki](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Ikiwa mradi wako unahifadhiwa kwenye GitHub, [unaweza kuona](https://help.github.com/articles/about-repository-graphs/#traffic) ni watu wangapi wanaotembelea mradi wako na wanatoka wapi. Kutoka kwenye ukurasa wa mradi wako, bonyeza "Insights", kisha "Traffic". Katika ukurasa huu, unaweza kuona:
+Ikiwa mradi wako unahifadhiwa kwenye GitHub, [unaweza kuona](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) ni watu wangapi wanaotembelea mradi wako na wanatoka wapi. Kutoka kwenye ukurasa wa mradi wako, bonyeza "Insights", kisha "Traffic". Katika ukurasa huu, unaweza kuona:
 
 * **Total page views:** Inakuambia ni mara ngapi mradi wako umekaguliwa
 
@@ -47,7 +47,7 @@ Ikiwa mradi wako unahifadhiwa kwenye GitHub, [unaweza kuona](https://help.github
 
 * **Popular content:** Inakuambia wageni wanakoenda kwenye mradi wako, ikigawanywa kwa maoni na wageni wa kipekee.
 
-[GitHub stars](https://help.github.com/articles/about-stars/) pia zinaweza kusaidia kutoa kipimo cha msingi cha umaarufu. Ingawa nyota za GitHub hazihusiani moja kwa moja na upakuaji na matumizi, zinaweza kukuambia ni watu wangapi wanachukua tahadhari kwa kazi yako.
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) pia zinaweza kusaidia kutoa kipimo cha msingi cha umaarufu. Ingawa nyota za GitHub hazihusiani moja kwa moja na upakuaji na matumizi, zinaweza kukuambia ni watu wangapi wanachukua tahadhari kwa kazi yako.
 
 Huenda pia ukataka [kufuatilia ugunduzi katika maeneo maalum](https://opensource.com/business/16/6/pirate-metrics): kwa mfano, Google PageRank, trafiki inayorejelea kutoka kwenye tovuti ya mradi wako, au marejeleo kutoka kwa miradi mingine ya open source au tovuti.
 
diff --git a/_articles/sw/starting-a-project.md b/_articles/sw/starting-a-project.md
index e7ef9ee43f3..3fd1934fd3d 100644
--- a/_articles/sw/starting-a-project.md
+++ b/_articles/sw/starting-a-project.md
@@ -107,9 +107,9 @@ Kwa ujumla, unapaswa kufungua mradi wako unapojisikia vizuri kuwa na wengine wan
 
 Bila kujali hatua gani unachagua kufungua mradi wako, kila mradi unapaswa kujumuisha nyaraka zifuatazo:
 
-* [Leseni ya open source](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)
-* [Miongozo ya kuchangia](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Leseni ya open source](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Miongozo ya kuchangia](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Kanuni ya tabia](../code-of-conduct/)
 
 Kama mtunza mradi, vipengele hivi vitakusaidia kuwasiliana matarajio, kusimamia michango, na kulinda haki za kisheria za kila mtu (ikiwemo yako mwenyewe). Vinapanua sana nafasi zako za kuwa na uzoefu mzuri.
@@ -189,7 +189,7 @@ Kadri muda unavyosonga, unaweza kuongeza maswali mengine yanayoulizwa mara kwa m
 
 Kwa msaada zaidi wa kuandika faili yako ya CONTRIBUTING, angalia mwongozo wa @nayafia [template ya kuchangia](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) au ["Jinsi ya Kujenga CONTRIBUTING.md" ya @mozilla](https://mozillascience.github.io/working-open-workshop/contributing/).
 
-Linki kwa faili yako ya CONTRIBUTING kutoka kwenye README yako, ili watu wengi zaidi waione. Ikiwa [uweka faili ya CONTRIBUTING kwenye hazina ya mradi wako](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub itaunganisha moja kwa moja kwenye faili yako wakati mchangiaji anaunda suala au kufungua ombi la kuvuta.
+Linki kwa faili yako ya CONTRIBUTING kutoka kwenye README yako, ili watu wengi zaidi waione. Ikiwa [uweka faili ya CONTRIBUTING kwenye hazina ya mradi wako](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), GitHub itaunganisha moja kwa moja kwenye faili yako wakati mchangiaji anaunda suala au kufungua ombi la kuvuta.
 
 ![Miongozo ya kuchangia](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -262,7 +262,7 @@ Sio lazima kuandika mwongozo wa mtindo kwa mradi wako unapokuwa unaanza, na unaw
 
 ## Orodha yako ya ukaguzi kabla ya uzinduzi
 
-Je, uko tayari kuweka mradi wako open source? Hapa kuna orodha ya ukaguzi ili kusaidia. Je, umekagua masanduku yote? Uko tayari kwenda! [Bonyeza "chapisha"](https://help.github.com/articles/making-a-private-repository-public/) na ujipatie sifa.
+Je, uko tayari kuweka mradi wako open source? Hapa kuna orodha ya ukaguzi ili kusaidia. Je, umekagua masanduku yote? Uko tayari kwenda! [Bonyeza "chapisha"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) na ujipatie sifa.
 
 **Nyaraka**
 
diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md
index c41c8e01805..d96148bc945 100644
--- a/_articles/ta/best-practices.md
+++ b/_articles/ta/best-practices.md
@@ -213,7 +213,7 @@ related:
 
 சோதனைகள், பங்களிப்பாளர்களுக்கு அவர்கள் எதையும் உடைக்க மாட்டார்கள் என்று நம்பிக்கையை தருகிறது. விரைவாக பங்களிப்புகளை மதிப்பாய்வு செய்து ஏற்றுக்கொள்வதற்கும் அவை எளிதாக்குகின்றன. நீங்கள் துரிதமாக பதிலளிக்கிறீர்கள் என்றால், உங்கள் சமுதாயத்தை இன்னும் அதிகமாக ஈடுபடுத்தலாம்.
 
-அனைத்து எதிர்வரும் பங்களிப்புகளை இயக்கும் தானியங்கு சோதனைகள் அமைக்கவும், உங்கள் சோதனைகளை எளிதில் பங்களிப்பவர்களால் இயக்க முடியும் என்பதை உறுதி செய்யவும். அனைத்து குறியீட்டு பங்களிப்புகளும் சமர்ப்பிக்கப்படுவதற்கு முன் உங்கள் சோதனைகளை கடக்க வேண்டும். எல்லா சமர்ப்பிப்புகளுக்குமான குறைந்தபட்ச தரமான தரத்தை அமைக்க உதவுவீர்கள். கிட்ஹப்-இல் [தேவைப்படும் நிலை சரிபார்ப்புக்கள்](https://help.github.com/articles/about-required-status-checks/) உங்கள் சோதனைகளை கடந்துசெல்லாமல் மாற்றம் எதுவும் சேர்க்கப்படாது என்பதை உறுதிப்படுத்த உதவுகிறது.
+அனைத்து எதிர்வரும் பங்களிப்புகளை இயக்கும் தானியங்கு சோதனைகள் அமைக்கவும், உங்கள் சோதனைகளை எளிதில் பங்களிப்பவர்களால் இயக்க முடியும் என்பதை உறுதி செய்யவும். அனைத்து குறியீட்டு பங்களிப்புகளும் சமர்ப்பிக்கப்படுவதற்கு முன் உங்கள் சோதனைகளை கடக்க வேண்டும். எல்லா சமர்ப்பிப்புகளுக்குமான குறைந்தபட்ச தரமான தரத்தை அமைக்க உதவுவீர்கள். கிட்ஹப்-இல் [தேவைப்படும் நிலை சரிபார்ப்புக்கள்](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) உங்கள் சோதனைகளை கடந்துசெல்லாமல் மாற்றம் எதுவும் சேர்க்கப்படாது என்பதை உறுதிப்படுத்த உதவுகிறது.
 
 நீங்கள் சோதனையைச் சேர்த்தால், உங்கள் பங்களிப்புக் கோப்பில் (CONTRIBUTING file) அவர்கள் எவ்வாறு வேலை செய்கின்றன என்பதை விளக்கிச் சொல்லுங்கள்.
 
diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md
index f7e17cdb471..62fa1ca49a1 100644
--- a/_articles/ta/building-community.md
+++ b/_articles/ta/building-community.md
@@ -166,7 +166,7 @@ related:
 
 * **ஒவ்வொரு பங்களிப்பாளரும் ஒப்பவிக்கும் அனுமதி தரவும்.** இது மக்களை [அவர்களின் இணைப்புகளை மெருகூட்டுவதற்கு மிகவும் உற்சாகமாக இருக்கிறது](https://felixge.de/2013/03/11/the-pull-request-hack.html)என்று @felixge கண்டறிந்தார், மேலும் அவர் சமீபத்தில் வேலை செய்யாத திட்டங்களில் கூட புதிய பராமரிப்பாளர்களைக் கண்டார்.
 
-* உங்கள் திட்டம் கிட்ஹப் இல் இருந்தால், **உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு [அமைப்பாக](https://help.github.com/articles/creating-a-new-organization-account/)** மாற்றவும் மற்றும் குறைந்தது ஒரு காப்பு நிர்வாகியை சேர்க்கவும். வெளிப்புற ஒத்துழைப்பாளர்களுடன் திட்டங்களில் வேலை செய்வதை நிறுவனங்கள் எளிதாக்குகின்றன.
+* உங்கள் திட்டம் கிட்ஹப் இல் இருந்தால், **உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு [அமைப்பாக](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)** மாற்றவும் மற்றும் குறைந்தது ஒரு காப்பு நிர்வாகியை சேர்க்கவும். வெளிப்புற ஒத்துழைப்பாளர்களுடன் திட்டங்களில் வேலை செய்வதை நிறுவனங்கள் எளிதாக்குகின்றன.
 
 உண்மை என்னவென்றால், [பெரும்பாலான திட்டங்களுக்கு](https://peerj.com/preprints/1233/) பெரும்பாலான வேலைகள் செய்யக்கூடிய ஒன்று அல்லது இரண்டு பராமரிப்பாளர்கள் இருப்பர். பெரிய திட்டம், மற்றும் உங்கள் சமூகம் பெரியதாக இருப்பின், எளிதாக உதவியை கண்டுபிடிக்க முடியும்.
 
diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md
index 745102a6bef..008d195c7d0 100644
--- a/_articles/ta/how-to-contribute.md
+++ b/_articles/ta/how-to-contribute.md
@@ -434,7 +434,7 @@ master கிளையில் ஒப்படைப்பு செயல்
 
 நீங்கள் ஒரு சிக்கலைத் திறக்க அல்லது கோரிக்கையை முன்வைக்கும் முன், திட்டத்தின் பங்களிப்பு ஆவணங்களை (வழக்கமாக கோப்பினைக் குறிக்கும் CONTRIBUTING அல்லது README இல்) பார்க்கவும். உதாரணமாக, நீங்கள் ஒரு வார்ப்புருவை பின்தொடர வேண்டுமென அவர்கள் கேட்கலாம் அல்லது நீங்கள் சோதனையைப் பயன்படுத்த வேண்டும்.
 
-நீங்கள் கணிசமான பங்களிப்பைச் செய்ய விரும்பினால், அதைத் தொடங்குவதற்கு முன் ஒரு சிக்கலைத் திறக்கவும். இது சிறிது நேரம் திட்டத்தைக் கவனிக்க உதவுகிறது (கிட்ஹப்பில், [நீங்கள் "கவனி" என்பதை கிளிக் செய்யலாம்](https://help.github.com/articles/watching-repositories/) அனைத்து உரையாடல்களையும் தெரியப்படுத்த வேண்டும்), மற்றும் சமுதாய உறுப்பினர்களை தெரிந்துகொள்ளுங்கள், ஏற்றுக்கொள்ள முடியாத வேலைகளை செய்வதற்கு முன்.
+நீங்கள் கணிசமான பங்களிப்பைச் செய்ய விரும்பினால், அதைத் தொடங்குவதற்கு முன் ஒரு சிக்கலைத் திறக்கவும். இது சிறிது நேரம் திட்டத்தைக் கவனிக்க உதவுகிறது (கிட்ஹப்பில், [நீங்கள் "கவனி" என்பதை கிளிக் செய்யலாம்](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) அனைத்து உரையாடல்களையும் தெரியப்படுத்த வேண்டும்), மற்றும் சமுதாய உறுப்பினர்களை தெரிந்துகொள்ளுங்கள், ஏற்றுக்கொள்ள முடியாத வேலைகளை செய்வதற்கு முன்.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -469,7 +469,7 @@ master கிளையில் ஒப்படைப்பு செயல்
 
 திட்டம் கிட்ஹப்பில் இருந்தால், இங்கே எப்படி ஒரு இழு கோரிக்கை சமர்ப்பிக்க வேண்டும்:
 
-* **[களங்சியத்தை கவர்வழி](https://guides.github.com/activities/forking/)** மற்றும் அதை உள்நாட்டில் நகலெடுக்கவும். அசல் "பாய்வு மேற்புறம்(upstream)" களஞ்சியத்தை தொலைதூரமாக சேர்ப்பதன் மூலம் உங்கள் உள்ளூர் இணைப்பை இணைக்கவும். "பாய்வு மேற்புறத்தில்" இருந்து மாற்றங்களை இழுக்கவும், அதனால் நீங்கள் புதுப்பித்த நிலையில் இருப்பீர்கள், உங்கள் குறைநிரப்புக் கோரிக்கையைச் சமர்ப்பிக்கும் போது, மோதல்கள் குறைவாக இருக்கும். (மேலும் விரிவான விவரங்களுக்கு [இங்கே](https://help.github.com/articles/syncing-a-fork/) பார்க்கவும்.)
+* **[களங்சியத்தை கவர்வழி](https://guides.github.com/activities/forking/)** மற்றும் அதை உள்நாட்டில் நகலெடுக்கவும். அசல் "பாய்வு மேற்புறம்(upstream)" களஞ்சியத்தை தொலைதூரமாக சேர்ப்பதன் மூலம் உங்கள் உள்ளூர் இணைப்பை இணைக்கவும். "பாய்வு மேற்புறத்தில்" இருந்து மாற்றங்களை இழுக்கவும், அதனால் நீங்கள் புதுப்பித்த நிலையில் இருப்பீர்கள், உங்கள் குறைநிரப்புக் கோரிக்கையைச் சமர்ப்பிக்கும் போது, மோதல்கள் குறைவாக இருக்கும். (மேலும் விரிவான விவரங்களுக்கு [இங்கே](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork) பார்க்கவும்.)
 * **[கிளை ஒன்றை உருவாக்கவும்](https://guides.github.com/introduction/flow/)** உங்கள் திருத்தங்களுக்கு.
 * **எந்தவொரு தொடர்படைய விடயங்களையும்** அல்லது ஆதரிக்கும் ஆவணங்களை உங்கள் PR இல் குறிப்பிடவும்(எடுத்துக்காட்டாக, "# 37 மூடுகிறது.")
 * உங்கள் மாற்றங்கள் HTML / CSS இல் உள்ள வேறுபாடுகளை உள்ளடக்கியிருந்தால்,**அதற்கு முன்பும் பின்பும் திரைக்காட்சிகளையும் சேர்க்கவும்**. உங்கள் இழு கோரிக்கையின் உடலில் படங்களை இழுத்து விடுங்கள்.
diff --git a/_articles/ta/leadership-and-governance.md b/_articles/ta/leadership-and-governance.md
index 79826735efd..b1310ac4c9e 100644
--- a/_articles/ta/leadership-and-governance.md
+++ b/_articles/ta/leadership-and-governance.md
@@ -73,7 +73,7 @@ related:
 
 [Vossibility](https://github.com/icecrime/vossibility-stack) போன்ற கருவிகள் திட்டத்திற்கு யார் பங்களிப்புகளை தருகிறார் (அல்லது தரவில்லை) என்பதைத் தெரிந்துகொள்ள உதவும். இந்த தகவலை ஆவணப்படுத்துவது, பராமரிப்பாளர்கள் தனிப்பட்ட முறையில் அதன் முடிவுகளை எடுக்கும் ஒரு குழு என்று சமூக அக்கறை தவிர்க்கிறது.
 
-இறுதியாக, உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு நிறுவனத்திற்கு நகர்த்துவதைக் கருத்தில் கொண்டு, குறைந்தது ஒரு காப்பு நிர்வாகி ஒன்றைச் சேர்ப்பதை கருத்தில் கொள்ளுங்கள். [கிட்ஹப் நிறுவனங்கள்](https://help.github.com/articles/creating-a-new-organization-account/) அனுமதிகள் மற்றும் பல களஞ்சியங்களை நிர்வகிக்க எளிதாக்குகின்றன, மேலும் உங்கள் திட்டத்தின் மரபுரிமைகளை [பகிரப்பட்ட உரிமையாளர்](../building-community/#share-ownership-of-your-project) மூலம் பாதுகாக்கின்றன.
+இறுதியாக, உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு நிறுவனத்திற்கு நகர்த்துவதைக் கருத்தில் கொண்டு, குறைந்தது ஒரு காப்பு நிர்வாகி ஒன்றைச் சேர்ப்பதை கருத்தில் கொள்ளுங்கள். [கிட்ஹப் நிறுவனங்கள்](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) அனுமதிகள் மற்றும் பல களஞ்சியங்களை நிர்வகிக்க எளிதாக்குகின்றன, மேலும் உங்கள் திட்டத்தின் மரபுரிமைகளை [பகிரப்பட்ட உரிமையாளர்](../building-community/#share-ownership-of-your-project) மூலம் பாதுகாக்கின்றன.
 
 ## எப்போது யாருக்கு ஒப்புவிக்கும் அணுகல் கொடுக்க வேண்டும்?
 
@@ -81,7 +81,7 @@ related:
 
 மறுபுறம், குறிப்பாக பெரிய, மிகவும் சிக்கலான செயல்திட்டங்களுக்கான, நீங்கள் அவர்களின் அர்ப்பணிப்பை நிரூபிக்கியுள்ள மக்களுக்கு மட்டுமே அனுமதி வழங்க வேண்டும். அதை செய்ய எந்த ஒரு சரியான வழி இல்லை - உங்களுக்கு மிகவும் வசதியாக உள்ள வழியில் செய்க!
 
-உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், ஒரு குறிப்பிட்ட கிளைக்கு யார் தள்ள முடியும், எந்த சூழ்நிலையிலும் நிர்வகிக்க நீங்கள் [பாதுகாக்கப்பட்ட கிளைகள்](https://help.github.com/articles/about-protected-branches/) பயன்படுத்தலாம்.
+உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், ஒரு குறிப்பிட்ட கிளைக்கு யார் தள்ள முடியும், எந்த சூழ்நிலையிலும் நிர்வகிக்க நீங்கள் [பாதுகாக்கப்பட்ட கிளைகள்](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) பயன்படுத்தலாம்.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index 9076b80168e..77c116686c4 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -28,7 +28,7 @@ related:
 
 ## கிட்ஹப்பில் உள்ள பொது திட்டங்கள் திறந்த மூலமா?
 
-கிட்ஹப்பில் நீங்கள் [புதிய திட்டம் ஒன்றை உருவாக்கும்](https://help.github.com/articles/creating-a-new-repository/) போது, **தனிப்பட்ட** அல்லது **பகிரங்கமான** களஞ்சியமாக உருவாக்க விருப்பத்தேர்வுகள் உள்ளன.
+கிட்ஹப்பில் நீங்கள் [புதிய திட்டம் ஒன்றை உருவாக்கும்](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) போது, **தனிப்பட்ட** அல்லது **பகிரங்கமான** களஞ்சியமாக உருவாக்க விருப்பத்தேர்வுகள் உள்ளன.
 
 ![களஞ்சியத்தை உருவாக்கவும்](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ related:
 
 [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/) காணலாம்.
 
-நீங்கள் கிட்ஹப்பில் ஒரு புதிய திட்டத்தை உருவாக்கும்போது, நீங்கள் [உரிமத்தைச் சேர்க்கும்படி கேட்கப்படும்](https://help.github.com/articles/open-source-licensing/).
+நீங்கள் கிட்ஹப்பில் ஒரு புதிய திட்டத்தை உருவாக்கும்போது, நீங்கள் [உரிமத்தைச் சேர்க்கும்படி கேட்கப்படும்](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
 
 ## எனது திட்டத்திற்கு கூடுதல் பங்களிப்பு ஒப்பந்தம் வேண்டுமா?
 
-அநேகமாக இல்லை. பெரும்பாலான திறந்த மூல திட்டங்களுக்கு,திறந்த மூல உரிமம் உட்குறிப்பாக (பங்களிப்பாளர்களிடமிருந்து) மற்றும் வெளியில் (மற்ற பங்களிப்பாளர்களுக்கும் பயனர்களுக்கும்) உரிமம் வழங்கப்படுகிறது. உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், கிட்ஹப் சேவை விதிமுறைகள் "inbound=outbound" [வெளிப்படையான இயல்புநிலை](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+அநேகமாக இல்லை. பெரும்பாலான திறந்த மூல திட்டங்களுக்கு,திறந்த மூல உரிமம் உட்குறிப்பாக (பங்களிப்பாளர்களிடமிருந்து) மற்றும் வெளியில் (மற்ற பங்களிப்பாளர்களுக்கும் பயனர்களுக்கும்) உரிமம் வழங்கப்படுகிறது. உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், கிட்ஹப் சேவை விதிமுறைகள் "inbound=outbound" [வெளிப்படையான இயல்புநிலை](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license).
 
 ஒரு கூடுதல் பங்களிப்பு ஒப்பந்தம் - பெரும்பாலும் ஒரு பங்களிப்பு உரிம ஒப்பந்தம் (CLA) - திட்டம் பராமரிப்பாளர்களுக்கு நிர்வாக வேலை உருவாக்க முடியும். திட்டம் மற்றும் செயல்படுத்தலில் ஒரு ஒப்பந்தம் எவ்வளவு வேலை செய்கிறது என்பதைப் பொறுத்தது. ஒரு எளிய உடன்படிக்கை பங்களிப்பாளர்கள், திட்டத்தின் திறந்த மூல உரிமத்தின் கீழ் பங்களிப்பு செய்வதற்கு அவசியமான உரிமைகள் இருப்பதாக ஒரு சொடுக்கு மூலம் உறுதிப்படுத்திக்கொள்ள வேண்டும். ஒரு சிக்கலான ஒப்பந்தம், பங்களிப்பாளர்களின் முதலாளிகளிடமிருந்து சட்டப்பூர்வ மதிப்பாய்வு மற்றும் கையொப்பமிட வேண்டும்.
 
diff --git a/_articles/ta/metrics.md b/_articles/ta/metrics.md
index df0cebdcaa1..1784a60f14d 100644
--- a/_articles/ta/metrics.md
+++ b/_articles/ta/metrics.md
@@ -37,7 +37,7 @@ related:
 
 ![போக்குவரத்து வரைபடம்](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-உங்கள் திட்டம் கிட்ஹப் இல் வழங்கப்பட்டிருந்தால், உங்கள் திட்டத்திற்கு எத்தனை பேர் வருகிறார்கள் மற்றும் எங்கிருந்து வருகிறார்கள் என்பதை [நீங்கள் காணலாம்](https://help.github.com/articles/about-repository-graphs/#traffic). உங்கள் திட்டத்தின் பக்கத்திலிருந்து, "நுண்ணறிவு" என்பதைக் கிளிக் செய்து, பின்னர் "போக்குவரத்து" என்பதைக் கிளிக் செய்யவும். இந்த பக்கத்தில், நீங்கள் பார்க்க கூடியது:
+உங்கள் திட்டம் கிட்ஹப் இல் வழங்கப்பட்டிருந்தால், உங்கள் திட்டத்திற்கு எத்தனை பேர் வருகிறார்கள் மற்றும் எங்கிருந்து வருகிறார்கள் என்பதை [நீங்கள் காணலாம்](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository). உங்கள் திட்டத்தின் பக்கத்திலிருந்து, "நுண்ணறிவு" என்பதைக் கிளிக் செய்து, பின்னர் "போக்குவரத்து" என்பதைக் கிளிக் செய்யவும். இந்த பக்கத்தில், நீங்கள் பார்க்க கூடியது:
 
 * **மொத்த பக்கம் நோக்குகள்:** எத்தனை முறை உங்கள் திட்டம் பார்க்கப்பட்டது என்று உங்களுக்கு சொல்கிறது
 
@@ -47,7 +47,7 @@ related:
 
 * **பிரபலமான உள்ளடக்கம்:** பார்வையாளர்கள் உங்கள் திட்டத்தில் எங்கு செல்கிறார்கள், பக்கம் நோக்குகள் மற்றும் தனித்துவமான பார்வையாளர்களால் பிரிக்கப்பட்டு உங்களுக்குத் தெரிவிக்கும்.
 
-[கிட்ஹப் நட்சத்திரங்கள்](https://help.github.com/articles/about-stars/) பிரபலத்தின் அடிப்படை அளவை வழங்க உதவுகிறது. கிட்ஹப் நட்சத்திரங்கள் பதிவிறக்கங்கள் மற்றும் பயன்பாட்டுடன் அவசியம் தொடர்பில்லை என்றாலும், உங்கள் வேலையை எத்தனை பேர் கவனிக்கிறார்களென அவை உங்களுக்கு சொல்ல முடியும்.
+[கிட்ஹப் நட்சத்திரங்கள்](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) பிரபலத்தின் அடிப்படை அளவை வழங்க உதவுகிறது. கிட்ஹப் நட்சத்திரங்கள் பதிவிறக்கங்கள் மற்றும் பயன்பாட்டுடன் அவசியம் தொடர்பில்லை என்றாலும், உங்கள் வேலையை எத்தனை பேர் கவனிக்கிறார்களென அவை உங்களுக்கு சொல்ல முடியும்.
 
 நீங்கள் [குறிப்பிட்ட இடங்களில் கண்டுபிடிப்பதை கண்டறியலாம்](https://opensource.com/business/16/6/pirate-metrics):  எடுத்துக்காட்டாக, கூகுள் பக்க தரவரிசை, உங்கள் திட்டத்தின் வலைத்தளத்திலிருந்து பரிந்துரைத்த போக்குவரத்து, அல்லது பிற திறந்த மூல திட்டங்கள் அல்லது வலைத்தளங்களில் இருந்து பரிந்துரைகளை வழங்குகிறது.
 
diff --git a/_articles/ta/starting-a-project.md b/_articles/ta/starting-a-project.md
index c6dfb4b8c02..5d74516647d 100644
--- a/_articles/ta/starting-a-project.md
+++ b/_articles/ta/starting-a-project.md
@@ -113,9 +113,9 @@ related:
 
 எந்த கட்டத்தில் நீங்கள் உங்கள் திட்டத்தை திறக்க முடிவு செய்தாலும், ஒவ்வொரு திட்டமும் பின்வரும் ஆவணங்கள் சேர்க்கப்பட வேண்டும்:
 
-* [திறந்த மூல உரிமம்](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)
-* [பங்களிப்பு நெறிமுறைகள்](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [திறந்த மூல உரிமம்](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [பங்களிப்பு நெறிமுறைகள்](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [நடத்தை குறியீடு](../code-of-conduct/)
 
 ஒரு பராமரிப்பாளராக, இந்த கூறுகள் எதிர்பார்ப்புகளைத் தொடர்புகொள்வதற்கும், பங்களிப்புகளை நிர்வகிப்பதற்கும், எல்லோருடைய சட்ட உரிமைகளையும் (உங்கள் சொந்த உள்ளடங்கலாக) பாதுகாக்கும். அவர்கள் நேர்மறையான அனுபவத்தைப் பெற்றிருப்பதற்கான வாய்ப்புகளை கணிசமாக அதிகரிக்கிறார்கள்.
@@ -189,7 +189,7 @@ README கள் உங்கள் திட்டத்தை எவ்வா
 
 உங்கள் பங்களிப்புக் கோப்பை எழுதுவதற்கு அதிக உதவிக்காக, @nayafia இன் [பங்களிப்பு வழிகாட்டி வார்ப்புரு](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) அல்லது @mozilla's ["எப்படி ஒரு CONTRIBUTING.md உருவாக்கவும்"](Https://mozillascience.github.io/working-open-workshop/contributing/) என பார்க்கவும்.
 
-உங்கள் README லிருந்து உங்கள் பங்களிப்பு கோப்பினை இணைக்க, அதிகமானோர் அதைப் பார்க்கிறார்கள். நீங்கள் ஒரு [பங்களிப்பு கோப்பு உங்கள் திட்டத்தின் களஞ்சியத்தில் வைக்கும்போது](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), உங்கள் பங்களிப்பாளர் ஒரு சிக்கல் உருவாக்கும் போது அல்லது ஒரு மிகுதிக் கோரிக்கையைத் திறக்கும் போது கிட்ஹப் தானாகவே கோப்பில் இணைக்கப்படும்
+உங்கள் README லிருந்து உங்கள் பங்களிப்பு கோப்பினை இணைக்க, அதிகமானோர் அதைப் பார்க்கிறார்கள். நீங்கள் ஒரு [பங்களிப்பு கோப்பு உங்கள் திட்டத்தின் களஞ்சியத்தில் வைக்கும்போது](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), உங்கள் பங்களிப்பாளர் ஒரு சிக்கல் உருவாக்கும் போது அல்லது ஒரு மிகுதிக் கோரிக்கையைத் திறக்கும் போது கிட்ஹப் தானாகவே கோப்பில் இணைக்கப்படும்
 
 ![பங்களிப்பு நெறிமுறைகள்](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -262,7 +262,7 @@ README கள் உங்கள் திட்டத்தை எவ்வா
 
 ## உங்கள் முன்-வெளியீட்டு பட்டியல்
 
-உங்கள் திட்டத்தைத் திறக்க தயாரா? உதவிக்கு ஒரு பட்டியல் இங்கே. அனைத்து பெட்டிகளையும் சரிபார்க்கவும்? நீங்கள் செல்ல தயாராக உள்ளீர்கள்! ["வெளியிடு" என்பதைக் சொடுக்கவும்](https://help.github.com/articles/making-a-private-repository-public/) பின்பு உங்களை நீங்களே தட்டிக்கொடுத்து கொள்ளவும்.
+உங்கள் திட்டத்தைத் திறக்க தயாரா? உதவிக்கு ஒரு பட்டியல் இங்கே. அனைத்து பெட்டிகளையும் சரிபார்க்கவும்? நீங்கள் செல்ல தயாராக உள்ளீர்கள்! ["வெளியிடு" என்பதைக் சொடுக்கவும்](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) பின்பு உங்களை நீங்களே தட்டிக்கொடுத்து கொள்ளவும்.
 
 **ஆவணப்படுத்தல்**
 
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 8f25c0418ff..2b851214f6d 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -165,7 +165,7 @@ Her şeyi kendiniz yapmak zorunda değilsiniz. Projenizin topluluğunun olmasın
 
 Başkalarının işe girişmesini istiyorsanız, bu dile getirerek başlayın.
 
-Yeni katılımcılar kazanmanın bir yolu da [yeni katılanlar için kolay çözülebilecek sorunları belirmektir](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub bu sorunları platform üzerindeki farklı sayfalarda göstererek farkedilebilir olmalarını sağlayacaktır.
+Yeni katılımcılar kazanmanın bir yolu da [yeni katılanlar için kolay çözülebilecek sorunları belirmektir](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels). GitHub bu sorunları platform üzerindeki farklı sayfalarda göstererek farkedilebilir olmalarını sağlayacaktır.
 
 Katkıda bulunan arasında yeni olanları gördüğünüzde, çalışmalarını daha fazla sorumluluk sunarak tanıyın. İsterlerse kendilerinin de yöneticilik rolüne nasıl dönüşebileceğini belgeleyin.
 
@@ -215,7 +215,7 @@ Projenizi otomatikleştirmenin en önemli yollarından biri de testler eklemekti
 
 Testler, katkıda bulunanların hiçbir şeyi kırmayacaklarından emin olmalarına yardımcı olur. Ayrıca katkıları hızla incelemenizi ve kabul etmenizi kolaylaştırır. Ne kadar duyarlı olursanız, toplumunuz o kadar adanmış olabilir.
 
-Tüm gelen katkılarda çalışacak otomatik testler ayarlayın ve testlerinizin katılımcılar tarafından kolayca yerel olarak çalıştırılabildiğinden emin olun. Tüm kod katkılarının gönderilmeden önce testlerinizi geçmesini şart koşun. Tüm gönderiler için minimum kalite standardı belirlenmesine yardımcı olmuş olacaksınız. GitHub'daki [zorunlu durum kontrolleri](https://help.github.com/articles/about-required-status-checks/) , testleriniz geçmeden değişiklik yapılmadan birleştirilmemesini sağlayabilir.
+Tüm gelen katkılarda çalışacak otomatik testler ayarlayın ve testlerinizin katılımcılar tarafından kolayca yerel olarak çalıştırılabildiğinden emin olun. Tüm kod katkılarının gönderilmeden önce testlerinizi geçmesini şart koşun. Tüm gönderiler için minimum kalite standardı belirlenmesine yardımcı olmuş olacaksınız. GitHub'daki [zorunlu durum kontrolleri](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) , testleriniz geçmeden değişiklik yapılmadan birleştirilmemesini sağlayabilir.
 
 Testler eklerseniz, CONTRIBUTING dosyanızda nasıl çalıştıklarını açıkladığınızdan emin olun.
 
diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index db9461e5b0e..2bc52849adf 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -28,7 +28,7 @@ Belgelerinizle başlayın:
 
 * **Birinin projenizi kullanmasını kolaylaştırın.** [Dostça bir README](../starting-a-project/#readme-yazma) ve sade kod örnekleri, projenize ulaşan herkesin başlamasını kolaylaştıracaktır.
 * [CONTRIBUTING dosyanızı](../starting-a-project/#katk%C4%B1da-bulunma-rehberinizi-yazmak) kullanarak ve sorun listenizi güncel tutarak **nasıl katkıda bulunulabileceğini açıkça belirtin**.
-* **Başlamak için iyi sorunlar**: Yeni katkıda bulunanların başlamasına yardımcı olmak için, [yeni başlayanların çözmesi için yeterince basit olan sorunları açıkça etiketlemeyi](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) düşünün. GitHub daha sonra bu sorunları platformda çeşitli yerlere taşıyacak, faydalı katkıları artıracak ve kullanıcıların seviyeleri için çok zor olan sorunlarla karşılaştırmayak sürtünmeyi azaltacak.
+* **Başlamak için iyi sorunlar**: Yeni katkıda bulunanların başlamasına yardımcı olmak için, [yeni başlayanların çözmesi için yeterince basit olan sorunları açıkça etiketlemeyi](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels) düşünün. GitHub daha sonra bu sorunları platformda çeşitli yerlere taşıyacak, faydalı katkıları artıracak ve kullanıcıların seviyeleri için çok zor olan sorunlarla karşılaştırmayak sürtünmeyi azaltacak.
 
 [GitHub'ın 2017 Açık Kaynak Anketi](http://opensourcesurvey.org/2017/) gösterdi ki açık kaynak kullanıcıları için en büyük problem yarım ya da karmaşık belgelerdir. İyi bir dökümantasyon insanların projeniz ile etkileşime geçmesini sağlar. Eninde sonunda birisi bir sorun bildirecek veya istekte bulunacaktır. Bu etkileşimleri, dönüşüm hunisinden aşağıya taşımak için fırsatlar olarak kullanın.
 
@@ -167,7 +167,7 @@ Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bul
 
 * **Her katkıda bulunana commit izni verin.** @felixge, bunun insanları [yamalarını geliştirme konusunda daha heyecanlı](https://felixge.de/2013/03/11/the-pull-request-hack.html) hale getirdiğini buldu ve bir süredir üzerinde çalışamadığı projeler için yeni geliştiriciler buldu.
 
-* Projeniz GitHub'daysa, **projenizi kişisel hesabınızdan bir [Organizasyona](https://help.github.com/articles/creating-a-new-organization-account/) hesabına taşıyın** ve en az bir yedek yönetici ekleyin. Organizasyon hesapları, harici çalışanlarla projeler üzerinde çalışmayı kolaylaştırır.
+* Projeniz GitHub'daysa, **projenizi kişisel hesabınızdan bir [Organizasyona](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) hesabına taşıyın** ve en az bir yedek yönetici ekleyin. Organizasyon hesapları, harici çalışanlarla projeler üzerinde çalışmayı kolaylaştırır.
 
 Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.com/preprints/1233/) bir veya iki geliştirici vardır. Projeniz büyüdükçe ve topluluğunuz büyüdükçe, yardım bulmak o kadar kolay olur.
 
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index f7f8f258c3b..375aafc195d 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -439,7 +439,7 @@ Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje
 
 Bir sorun açmadan veya talepte bulunmadan önce, belirli bir şey eklemeniz gerekip gerekmediğini görmek için projenin katkıda bulunma belgelerini (genellikle CONTRIBUTING veya README dosyaları) kontrol edin. Örneğin, bir şablon izlemenizi istenebilir veya test ortamı kullanmanız gerekebilir.
 
-Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://help.github.com/articles/watching-repositories/)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın.
+Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -474,7 +474,7 @@ Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genel
 
 Proje GitHub'taysa, PR nasıl gönderilir:
 
-* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream"  olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.)
+* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream"  olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork) daha ayrıntılı talimatlara bakın.)
 * Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** .
 * **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37")
 * Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz.
diff --git a/_articles/tr/leadership-and-governance.md b/_articles/tr/leadership-and-governance.md
index c7ff8e2ee48..4b3dfb0a96e 100644
--- a/_articles/tr/leadership-and-governance.md
+++ b/_articles/tr/leadership-and-governance.md
@@ -73,7 +73,7 @@ Liderlik rolleri belirledikten sonra, insanların onlara nasıl ulaşabileceğin
 
 [Vossibility](https://github.com/icecrime/vossibility-stack) gibi araçlar, projeye kimin katkı sağladığını (ya da yapmadığını) izlemenize yardımcı olabilir. Bu bilginin belgelenmesi, topluluk sahiplerinin, kararlarını özel olarak veren bir klik olduğuna inanmalarını engeller.
 
-Son olarak, projeniz GitHub'daysa, projenizi kişisel hesabınızdan bir organizasyon hesabına taşımayı ve en az bir yedek yönetici eklemeyi düşünün. [GitHub Organizasyonları](https://help.github.com/articles/creating-a-new-organization-account/) izinleri ve çoklu depoları yönetmeyi kolaylaştırır ve projenizin mirasını [ortak mülkiyet](../building-community/#projenizi-paylaşın) yoluyla korur.
+Son olarak, projeniz GitHub'daysa, projenizi kişisel hesabınızdan bir organizasyon hesabına taşımayı ve en az bir yedek yönetici eklemeyi düşünün. [GitHub Organizasyonları](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) izinleri ve çoklu depoları yönetmeyi kolaylaştırır ve projenizin mirasını [ortak mülkiyet](../building-community/#projenizi-paylaşın) yoluyla korur.
 
 ## Ne zaman birine commit izni vermeliyim?
 
@@ -81,7 +81,7 @@ Bazı insanlar katkıda bulunan herkese commit yetkisi vermeniz gerektiğini dü
 
 Öte yandan, özellikle daha büyük, daha karmaşık projeler için, yalnızca kendilerini kanıtlayan kişilere commit hakkı vermek isteyebilirsiniz. Bunu yapmanın doğru bir yolu yok - sizi en rahat ettiren şeyi yapın!
 
-Projeniz GitHub'daysa, belirli bir dala kimin ve hangi şartlar altında kod gönderebileceğini yönetmek için [korumalı dalları](https://help.github.com/articles/about-protected-branches/) kullanabilirsiniz.
+Projeniz GitHub'daysa, belirli bir dala kimin ve hangi şartlar altında kod gönderebileceğini yönetmek için [korumalı dalları](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) kullanabilirsiniz.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 84244d43e88..073172a349d 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -28,7 +28,7 @@ Son olarak, projeniz sizin bilmediğiniz lisans gereksinimlerine bağlı olabili
 
 ## Açık GitHub projeleri açık kaynak mı?
 
-GitHub'da [yeni bir proje oluşturduğunuzda](https://help.github.com/articles/creating-a-new-repository/), proje kütüphanesini **gizli** veya **açık** hale getirme seçeneğiniz vardır.
+GitHub'da [yeni bir proje oluşturduğunuzda](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository), proje kütüphanesini **gizli** veya **açık** hale getirme seçeneğiniz vardır.
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -42,7 +42,7 @@ Başkalarının projenizi kullanmasını, dağıtmasını, değiştirmesini veya
 
 [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ve [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) en popüler açık kaynaklı lisanslardır, ancak seçilebilecek başka seçenekler de vardır. [Choosealicense.com](https://choosealicense.com/)'da bu lisansların tam metnini ve nasıl kullanılacağına ilişkin talimatları bulabilirsiniz.
 
-GitHub'da yeni bir proje oluşturduğunuzda sizden [bir lisans eklemeniz istenir](https://help.github.com/articles/open-source-licensing/).
+GitHub'da yeni bir proje oluşturduğunuzda sizden [bir lisans eklemeniz istenir](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository).
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
@@ -88,7 +88,7 @@ Alternatif olarak, katkıda bulunanlara, mevcut açık kaynak lisansınız taraf
 
 ## Projemin ek bir katkı sözleşmesine ihtiyacı var mı?
 
-Muhtemelen yoktur. Açık kaynak projelerin büyük çoğunluğu için açık kaynaklı bir lisans, hem gelenler (katkıda bulunanlardan) hem de gidenler (diğer katkıda bulunanlar ve kullanıcılar için) için lisans olarak açık şekilde hizmet vermektedir. Projeniz GitHub'daysa, GitHub Hizmet Şartları "inbound = outbound" ı [açık varsayılan yapar](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license) .
+Muhtemelen yoktur. Açık kaynak projelerin büyük çoğunluğu için açık kaynaklı bir lisans, hem gelenler (katkıda bulunanlardan) hem de gidenler (diğer katkıda bulunanlar ve kullanıcılar için) için lisans olarak açık şekilde hizmet vermektedir. Projeniz GitHub'daysa, GitHub Hizmet Şartları "inbound = outbound" ı [açık varsayılan yapar](https://docs.github.com/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license) .
 
 Ek bir katılımcı sözleşmesi - genellikle Katılımcı Lisans Sözleşmesi (CLA) olarak adlandırılır - proje sahipleri için idari işler yaratabilir. Bir anlaşmanın ne kadar iş gerektirdiği proje ve uygulamaya bağlıdır. Basit bir anlaşma, katkıda bulunanların, bir tıklamayla, proje açık kaynak lisansı kapsamında katkıda bulunmak için gerekli haklara sahip olduklarını onaylamalarını gerektirebilir. Daha karmaşık bir anlaşma, katkıda bulunanların işverenlerinin yasal incelemesini ve imzalarını gerektirebilir.
 
diff --git a/_articles/tr/metrics.md b/_articles/tr/metrics.md
index 753ff7060fd..f86f7b78ab6 100644
--- a/_articles/tr/metrics.md
+++ b/_articles/tr/metrics.md
@@ -37,7 +37,7 @@ Herhangi biriniz projenizi kullanmadan veya katkıda bulunmadan önce, onun var
 
 ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-Projeniz GitHub'da barındırıyorsanız, projenizi kaç kişinin gördüğünü ve nereden geldikleri [görüntüleyebilirsiniz](https://help.github.com/articles/about-repository-graphs/#traffic). Projenizin sayfasından "Insights" menüsünü, ardından "Traffic" alt menüsünü tıklayın. Bu sayfada şunları görebilirsiniz:
+Projeniz GitHub'da barındırıyorsanız, projenizi kaç kişinin gördüğünü ve nereden geldikleri [görüntüleyebilirsiniz](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository). Projenizin sayfasından "Insights" menüsünü, ardından "Traffic" alt menüsünü tıklayın. Bu sayfada şunları görebilirsiniz:
 
 * **Toplam sayfa görüntüleme:** Projenizin kaç kez görüntülendiğini gösterir
 
@@ -47,7 +47,7 @@ Projeniz GitHub'da barındırıyorsanız, projenizi kaç kişinin gördüğünü
 
 * **Popüler içerik:** Ziyaretçilerin projenizde nereye gittiğini, sayfa görünümlerine ve benzersiz ziyaretçilere göre ayrıldığını gösterir.
 
-[GitHub yıldızları](https://help.github.com/articles/about-stars/) ayrıca temel bir popülarite ölçüsü sağlamaya yardımcı olabilir. GitHub yıldızları, indirmeler ve kullanımla mutlaka ilişkilendirilmezken, size kaç kişinin çalışmanızdan haberdar olduğunu söyleyebilirler.
+[GitHub yıldızları](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) ayrıca temel bir popülarite ölçüsü sağlamaya yardımcı olabilir. GitHub yıldızları, indirmeler ve kullanımla mutlaka ilişkilendirilmezken, size kaç kişinin çalışmanızdan haberdar olduğunu söyleyebilirler.
 
 [Belirli yerlerdeki keşfedilebilirliği izlemek](https://opensource.com/business/16/6/pirate-metrics) isteyebilirsiniz: örneğin, Google PageRank, projenizin web sitesinden yönlendirilen trafik veya diğer açık kaynaklı projelerden veya web sitelerinden gelen yönlendirmeler.
 
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 46d0b75a3c8..514ed99cc0d 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -106,9 +106,9 @@ Genel olarak konuşursak, başkalarının işinizi görmesini ve işiniz hakkın
 
 Projenizi hangi aşamada açmaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir:
 
-* [Açık kaynak lisansı](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)
-* [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Açık kaynak lisansı](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Katkıda bulunma kuralları](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Davranış kuralları](../code-of-conduct/)
 
 Bir geliştirici olarak, bu bileşenler beklentileri iletmenize, katkıları yönetmenize ve herkesin yasal haklarını (kendi haklarınız dahil) korumanıza yardımcı olur. Olumlu bir deneyim yaşama şansınızı önemli ölçüde artırırlar.
@@ -184,7 +184,7 @@ Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsin
 
 CONTRIBUTING dosyanızı yazarken daha fazla yardım için @nayafia'nın [katkıda bulunma rehber şablonuna](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz.
 
-README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan görsün. [CONTRIBUTING dosyasını projenizin deposuna yerleştirirseniz](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), bir katılımcı bir sorun oluşturduğunda veya bir PR açtığında GitHub otomatik olarak dosyanıza bağlanır.
+README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan görsün. [CONTRIBUTING dosyasını projenizin deposuna yerleştirirseniz](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors), bir katılımcı bir sorun oluşturduğunda veya bir PR açtığında GitHub otomatik olarak dosyanıza bağlanır.
 
 ### Davranış kural listesi oluşturmak
 
@@ -255,7 +255,7 @@ Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin ma
 
 ## Lansman öncesi kontrol listeniz
 
-Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol listesi. Tüm kutuları işaretleyin? Projeye açmaya hazırsın! ["publish"](https://help.github.com/articles/making-a-private-repository-public/) düğmesine basın ve arkanıza yaslanın.
+Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol listesi. Tüm kutuları işaretleyin? Projeye açmaya hazırsın! ["publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) düğmesine basın ve arkanıza yaslanın.
 
 **Belgeler**
 
diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index 471aa8210e1..861a448667a 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -435,7 +435,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 在你创建 issue 和 PR 之前，请检查项目的贡献者文档（文件名通常叫做 CONTRIBUTING，或者就直接包含在README中），找一些你需要的较具体的东西，例如，他们会要求你遵循某个模版，或者是要求你使用某个测试。
 
-如果你做的是一个非常实际的贡献，在正式开启之前，先创建一个 issue。Watch 这个项目是很有帮助的（在 GitHub，[点击 "Watch"](https://help.github.com/articles/watching-repositories/)，所有的对话都会通知你），要让社区的成员们知道你要做的工作，免得你做了之后，再让他们知道，他们不同意，就浪费了。
+如果你做的是一个非常实际的贡献，在正式开启之前，先创建一个 issue。Watch 这个项目是很有帮助的（在 GitHub，[点击 "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications)，所有的对话都会通知你），要让社区的成员们知道你要做的工作，免得你做了之后，再让他们知道，他们不同意，就浪费了。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -470,7 +470,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 如果说项目是托管在 GitHub 上的，以下是我们总结出的提交 PR 的建议：
 
-* **[Fork 代码仓库](https://guides.github.com/activities/forking/)** 并克隆到本地，在本地的仓库配置"上游"为远端仓库。这样你可以在提交你的 PR 时保持和"上游"同步，会减少很多解决冲突的时间。（更多关于同步的说明，请参考[这里](https://help.github.com/articles/syncing-a-fork/).）
+* **[Fork 代码仓库](https://guides.github.com/activities/forking/)** 并克隆到本地，在本地的仓库配置"上游"为远端仓库。这样你可以在提交你的 PR 时保持和"上游"同步，会减少很多解决冲突的时间。（更多关于同步的说明，请参考[这里](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork).）
 * **[创建一个分支](https://guides.github.com/introduction/flow/)** 用于自己编辑。
 * **参考任何相关的issue** 或者在你的 PR 中支持文档(比如. "Closes #37.")
 * **包含之前和之后的快照** 如果你的改动是包含了不同的 HTML/CSS。在你的 PR 中加入相应的图片。
diff --git a/_articles/zh-hans/leadership-and-governance.md b/_articles/zh-hans/leadership-and-governance.md
index 78edb21c7be..3ecfbc2025a 100644
--- a/_articles/zh-hans/leadership-and-governance.md
+++ b/_articles/zh-hans/leadership-and-governance.md
@@ -76,7 +76,7 @@ redirect_from: /zh-cn/leadership-and-governance/
 诸如[Vossibility](https://github.com/icecrime/vossibility-stack) 这样的工具，可以帮助你追踪谁是（或不是）项目的贡献者。为这些信息作说明，以避免社区出现维护者作出私自的决定。
 
 另外，如果你的项目在托管在GitHub上，考虑将你的项目从个人账户迁移到某个组织，而且要为组织增加额外的一个备份的管理员。
-[GitHub 上的组织](https://help.github.com/articles/creating-a-new-organization-account/) 能够让权限管理和多仓库管理更加的轻松，而且可通过 [共享所有权](../building-community/#共享项目所有权)来保护你的项目。
+[GitHub 上的组织](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) 能够让权限管理和多仓库管理更加的轻松，而且可通过 [共享所有权](../building-community/#共享项目所有权)来保护你的项目。
 
 ## 什么时候授予提交者权限？
 
@@ -84,7 +84,7 @@ redirect_from: /zh-cn/leadership-and-governance/
 
 换句话说，尤其是针对那些大型的、更加复杂的项目，你或许只是会给那些证明自己有能力提交代码的人赋予权限。这个没有一个确切的衡量标准，做你认为正确的就好了，或者是最让项目成员感到舒服的方式。
 
-假如项目是托管在GitHub上，可以使用[受保护的分支](https://help.github.com/articles/about-protected-branches/)来管理那些可以提交特定的分支情况。
+假如项目是托管在GitHub上，可以使用[受保护的分支](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)来管理那些可以提交特定的分支情况。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index a27acd2c5be..9e7c9910c75 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -29,7 +29,7 @@ redirect_from: /zh-cn/legal/
 
 ## GitHub上的公开项目都是开源的吗？
 
-当你们在GitHub上[创建一个新项目](https://help.github.com/articles/creating-a-new-repository/) 时，你们可以选择将仓库设置成**private**或者**public**。
+当你们在GitHub上[创建一个新项目](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) 时，你们可以选择将仓库设置成**private**或者**public**。
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -43,7 +43,7 @@ redirect_from: /zh-cn/legal/
 
 [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/)。
+当你们在GitHub上创建了一个新项目，你们会被[要求添加一个许可协议](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository)。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/zh-hans/metrics.md b/_articles/zh-hans/metrics.md
index f3189fc0790..c348072f01b 100644
--- a/_articles/zh-hans/metrics.md
+++ b/_articles/zh-hans/metrics.md
@@ -38,7 +38,7 @@ redirect_from: /zh-cn/metrics/
 
 ![traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-如果你的项目是托管在GitHub, 你可以[访问](https://help.github.com/articles/about-repository-graphs/#traffic) 获取诸如多少人访问过你的项目，他们从哪里得知的之类的信息。在你的项目主页，点击"Graphs", 然后"Traffic"。在这个页面，你可以看到:
+如果你的项目是托管在GitHub, 你可以[访问](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) 获取诸如多少人访问过你的项目，他们从哪里得知的之类的信息。在你的项目主页，点击"Graphs", 然后"Traffic"。在这个页面，你可以看到:
 
 * **总浏览量:** 项目被查看了多少次
 
@@ -48,7 +48,7 @@ redirect_from: /zh-cn/metrics/
 
 * **受欢迎的内容:** 访问者都查看了你项目的那些内容，按照页面访问量和独立访客数。
 
-[GitHub stars](https://help.github.com/articles/about-stars/) 可以提供一个基本的衡量流行度的标准。然而GitHub 点赞数并不和下载量、使用量直接挂钩，但是他可以告诉你有多少人在关注你的项目。
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) 可以提供一个基本的衡量流行度的标准。然而GitHub 点赞数并不和下载量、使用量直接挂钩，但是他可以告诉你有多少人在关注你的项目。
 
 你也许想要[在特定的地方跟踪可发现的内容](https://opensource.com/business/16/6/pirate-metrics): 举个例子，Google PageRank，会跟踪来自你项目网站的流量，或者跟踪来自其他开源项目或者网站的流量。
 
diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index 20fff338b81..8216bd76f91 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -114,9 +114,9 @@ redirect_from: /zh-cn/starting-a-project/
 
 无论您决定开展项目的哪个阶段，每个项目都应包括以下文档：
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 作为维护者，这些组件将帮助你交流你的期望，管理贡献并保护每个人的合法权益（也包括您自己的）。他们能够大大增加你积极体验的机会。
@@ -190,7 +190,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 想要获得更多有关编写贡献文件的方式，请查阅 @nayafia 的 [贡献指南模板](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) 或者 @mozilla 的 ["如何构建 CONTRIBUTION.md"](https://mozillascience.github.io/working-open-workshop/contributing/)。
 
-在你的 README 中链接你的 CONTRIBUTING，这样更多人就能看到他。如果你[在你的项目中放入了 CONTRIBUTING 文件](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)，当一个贡献者创建 issue 或者开启一个 pull request 时，GitHub 会自动链接你的文件。
+在你的 README 中链接你的 CONTRIBUTING，这样更多人就能看到他。如果你[在你的项目中放入了 CONTRIBUTING 文件](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)，当一个贡献者创建 issue 或者开启一个 pull request 时，GitHub 会自动链接你的文件。
 
 ![贡献指南](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -263,7 +263,7 @@ redirect_from: /zh-cn/starting-a-project/
 
 ## 发布项目之前的检查项
 
-准备好开源你的项目了吗？有一份帮助检查清单。检查所有内容？你准备开始吧！ [点击 "publish"](https://help.github.com/articles/making-a-private-repository-public/) 以及拍下自己的后背。
+准备好开源你的项目了吗？有一份帮助检查清单。检查所有内容？你准备开始吧！ [点击 "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) 以及拍下自己的后背。
 
 **文档**
 
diff --git a/_articles/zh-hant/building-community.md b/_articles/zh-hant/building-community.md
index 90c5937a31a..58ec0b077db 100644
--- a/_articles/zh-hant/building-community.md
+++ b/_articles/zh-hant/building-community.md
@@ -168,7 +168,7 @@ redirect_from: /zh-tw/building-community/
 
 * **給每個貢獻者提交的權限。**@發現這樣會使大家[越來越樂意發表他們的補丁](https://felixge.de/2013/03/11/the-pull-request-hack.html)，甚至找到人手來協助維護他已很久沒處理的專案。
 
-* 如果專案是放在 GitHub 上，那麼 **將專案從你們的個人賬號轉移到一個[組織](https://help.github.com/articles/collaborating-with-groups-in-organizations/)**，加入至少一個備份管理員。組織能讓社群與來自外界的貢獻，彼此協作的工作變得更加容易。
+* 如果專案是放在 GitHub 上，那麼 **將專案從你們的個人賬號轉移到一個[組織](https://docs.github.com/organizations/collaborating-with-groups-in-organizations)**，加入至少一個備份管理員。組織能讓社群與來自外界的貢獻，彼此協作的工作變得更加容易。
 
 事實上很多專案[只有一個或者兩個維護者](https://peerj.com/preprints/1233/)去做大部分的工作。隨著社群變得越來越大，就會有更多的人參與進來。
 
diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index ce1ff212d83..5070e254d11 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -434,7 +434,7 @@ redirect_from: /zh-tw/how-to-contribute/
 
 在你創建 issue 和 PR 之前，請檢查專案的貢獻者文件（文件名通常叫做 CONTRIBUTING，或者就直接寫在 README 中），找到你需要、較具體的東西，例如他們會要求你遵循某個樣板，或者是要求你使用某個測試。
 
-如果你想做一個重大的貢獻，在正式開始之前先創建一個 issue。監控專案是很有幫助的（在GitHub，[點擊 "Watch"](https://help.github.com/articles/watching-repositories/) ，所有當中的對話都會通知你），通知社群的成員們，讓大家知道你要做的工作，免得你做了之後，他們事後才知道。
+如果你想做一個重大的貢獻，在正式開始之前先創建一個 issue。監控專案是很有幫助的（在GitHub，[點擊 "Watch"](https://docs.github.com/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) ，所有當中的對話都會通知你），通知社群的成員們，讓大家知道你要做的工作，免得你做了之後，他們事後才知道。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars2.githubusercontent.com/u/810438?v=3&s=400" class="pquote-avatar" alt="avatar">
@@ -469,7 +469,7 @@ redirect_from: /zh-tw/how-to-contribute/
 
 如果說專案是託管在 GitHub 上，以下是我們對於提交 PR 的建議：
 
-* **[Fork 程式碼](https://guides.github.com/activities/forking/)** 並下載到自己的電腦，在本地端設定「上游」爲遠端倉庫。這樣你可以在提交你的 PR 時保持和「上游」同步，合併時會減少解決衝突的時間。（更多關於同步的說明，請參考[這裡](https://help.github.com/articles/syncing-a-fork/)。）
+* **[Fork 程式碼](https://guides.github.com/activities/forking/)** 並下載到自己的電腦，在本地端設定「上游」爲遠端倉庫。這樣你可以在提交你的 PR 時保持和「上游」同步，合併時會減少解決衝突的時間。（更多關於同步的說明，請參考[這裡](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork)。）
 * **[創建一個分支](https://guides.github.com/introduction/flow/)** 方便自己編輯。
 * **參考任何相關的 issue**或在你的 PR 中註記相關的文件（例如："Closes #37."）
 * **留下更動前後的螢幕截圖**，如果你修改了 HTML/CSS。在你的 PR 中放上截圖。
diff --git a/_articles/zh-hant/leadership-and-governance.md b/_articles/zh-hant/leadership-and-governance.md
index 6ba380ebe46..e9d7e36eee3 100644
--- a/_articles/zh-hant/leadership-and-governance.md
+++ b/_articles/zh-hant/leadership-and-governance.md
@@ -76,7 +76,7 @@ redirect_from: /zh-tw/leadership-and-governance/
 諸如[Vossibility](https://github.com/icecrime/vossibility-stack) 這樣的工具，可以幫助你追蹤誰是（或不是）專案的貢獻者。爲這些資訊作說明，以避免社群出現維護者作出私自的決定。
 
 另外，如果你的專案在託管在GitHub上，考慮將你的專案從個人賬戶遷移到某個組織，而且要爲組織增加額外的一個備份的管理員。
-[GitHub 上的組織](https://help.github.com/articles/creating-a-new-organization-account/) 能夠讓權限管理和多倉庫管理更加的輕鬆，而且可通過 [共享所有權](../building-community/#分享專案的所有權)來保護你的專案。
+[GitHub 上的組織](https://docs.github.com/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) 能夠讓權限管理和多倉庫管理更加的輕鬆，而且可通過 [共享所有權](../building-community/#分享專案的所有權)來保護你的專案。
 
 ## 何時該賦予提交者權限
 
@@ -84,7 +84,7 @@ redirect_from: /zh-tw/leadership-and-governance/
 
 換句話說，尤其是針對那些大型的、更加複雜的專案，你或許只是會給那些證明自己有能力提交程式碼的人賦予權限。這個沒有一個確切的衡量標準，做你認爲正確的就好了，或者是最讓專案成員感到舒服的方式。
 
-假如專案是託管在GitHub上，可以使用[受保護的分支](https://help.github.com/articles/about-protected-branches/)來管理那些可以提交特定的分支情況。
+假如專案是託管在GitHub上，可以使用[受保護的分支](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)來管理那些可以提交特定的分支情況。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars2.githubusercontent.com/u/15000?v=3&s=460" class="pquote-avatar" alt="avatar">
diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index 7da68d25d2a..fd49cb6732a 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -29,7 +29,7 @@ redirect_from: /zh-tw/legal/
 
 ## 公開的GitHub專案是開源的嗎
 
-當你們在GitHub上[創建一個新專案](https://help.github.com/articles/creating-a-new-repository/) 時，你們可以選擇將倉庫設置成**private**或者**public**。
+當你們在GitHub上[創建一個新專案](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository) 時，你們可以選擇將倉庫設置成**private**或者**public**。
 
 ![Create repository](/assets/images/legal/repo-create-name.png)
 
@@ -43,7 +43,7 @@ redirect_from: /zh-tw/legal/
 
 [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/)。
+當你們在GitHub上創建了一個新專案，你們會被[要求添加一個許可協議](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository)。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars2.githubusercontent.com/u/282759?v=3&s=400" class="pquote-avatar" alt="avatar">
diff --git a/_articles/zh-hant/metrics.md b/_articles/zh-hant/metrics.md
index 9fffa326ec7..f8ef092a9c6 100644
--- a/_articles/zh-hant/metrics.md
+++ b/_articles/zh-hant/metrics.md
@@ -38,7 +38,7 @@ redirect_from: /zh-tw/metrics/
 
 ![traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
-如果你的專案是託管在GitHub, 你可以[訪問](https://help.github.com/articles/about-repository-graphs/#traffic) 獲取諸如多少人訪問過你的專案，他們從哪裏得知的之類的資訊。在你的專案主頁，點擊"Graphs", 然後"Traffic"。在這個頁面，你可以看到:
+如果你的專案是託管在GitHub, 你可以[訪問](https://docs.github.com/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository) 獲取諸如多少人訪問過你的專案，他們從哪裏得知的之類的資訊。在你的專案主頁，點擊"Graphs", 然後"Traffic"。在這個頁面，你可以看到:
 
 * **總瀏覽量:** 專案被查看了多少次
 
@@ -48,7 +48,7 @@ redirect_from: /zh-tw/metrics/
 
 * **受歡迎的內容:** 訪問者都查看了你專案的那些內容，按照頁面訪問量和獨立訪客數。
 
-[GitHub stars](https://help.github.com/articles/about-stars/) 可以提供一個基本的衡量流行度的標準。然而GitHub 點贊數並不和下載量、使用量直接掛鉤，但是他可以告訴你有多少人在關注你的專案。
+[GitHub stars](https://docs.github.com/get-started/exploring-projects-on-github/saving-repositories-with-stars) 可以提供一個基本的衡量流行度的標準。然而GitHub 點贊數並不和下載量、使用量直接掛鉤，但是他可以告訴你有多少人在關注你的專案。
 
 你也許想要[在特定的地方跟蹤可發現的內容](https://opensource.com/business/16/6/pirate-metrics): 舉個例子，Google PageRank，會跟蹤來自你專案網站的流量，或者跟蹤來自其他開源專案或者網站的流量。
 
diff --git a/_articles/zh-hant/starting-a-project.md b/_articles/zh-hant/starting-a-project.md
index 65a75b30853..bd0400e181a 100644
--- a/_articles/zh-hant/starting-a-project.md
+++ b/_articles/zh-hant/starting-a-project.md
@@ -114,9 +114,9 @@ redirect_from: /zh-tw/starting-a-project/
 
 無論您決定開展專案的哪個階段，每個專案都應包括以下文檔：
 
-* [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/)
+* [Open source license](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license)
+* [README](https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-new-repository)
+* [Contributing guidelines](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
 * [Code of conduct](../code-of-conduct/)
 
 作爲維護者，這些組件將幫助你交流你的期望，管理貢獻並保護每個人的合法權益（也包括您自己的）。他們能夠大大增加你積極體驗的機會。
@@ -190,7 +190,7 @@ redirect_from: /zh-tw/starting-a-project/
 
 想要獲得更多有關編寫貢獻文件的方式，請查閱 @nayafia 的 [貢獻指南模板](https://github.com/nayafia/contributing-template/blob/HEAD/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 會自動鏈接你的文件。
+來你的 README 中鏈接你的 CONTRIBUTING，這樣更多人就能看到他。如果你[在你的專案中放入了 CONTRIBUTING 文件](https://docs.github.com/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)，當一個貢獻者創建 issue 或者開啓一個 pull request 時，GitHub 會自動鏈接你的文件。
 
 ![貢獻指南](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -263,7 +263,7 @@ redirect_from: /zh-tw/starting-a-project/
 
 ## 發起專案之前的檢查項
 
-準備好開源你的專案了嗎？有一份幫助檢查清單。檢查所有內容？你準備開始吧！ [點擊 "publish"](https://help.github.com/articles/making-a-private-repository-public/) 以及拍下自己的後背。
+準備好開源你的專案了嗎？有一份幫助檢查清單。檢查所有內容？你準備開始吧！ [點擊 "publish"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) 以及拍下自己的後背。
 
 **文檔**
 
diff --git a/docs/content-model.md b/docs/content-model.md
index 9ef6273b1c4..b04d1b22af4 100644
--- a/docs/content-model.md
+++ b/docs/content-model.md
@@ -5,8 +5,8 @@ This content was originally created and curated by GitHub, and covers topics tha
 
 For content that is specific to GitHub products, see:
 
-- [help.github.com](https://help.github.com) - gets existing users unstuck and back to work.
-- [guides.github.com](https://guides.github.com) - tutorials about a larger idea or product feature for new users.
+- [docs.github.com](https://docs.github.com) - gets existing users unstuck and back to work.
+- [skills.github.com](https://skills.github.com) - tutorials about a larger idea or product feature for new users.
 
 Everything written in the guides should fall into one of the following categories:
 
diff --git a/docs/translations.md b/docs/translations.md
index 7a1036b9f8e..5b744442e10 100644
--- a/docs/translations.md
+++ b/docs/translations.md
@@ -18,7 +18,7 @@ If there's not, then today is your day to lead this effort! Here's how to start:
 1. Run `script/test` and make sure there are no failures with your translation files. Note that you may need to fix broken links.
 1. Send a pull request. (You may send a pull request before all steps above are complete: e.g., you may want to ask for help with translations, or getting tests to pass. However, your pull request will not be merged until all steps above are complete.)
 
-Completing an initial translation of the whole site is a fairly large task. One way to break that task up is to work with other translators through pull requests on your fork. Example: [pull requests on fork for German translation](https://github.com/katrinleinweber/opensource.guide/pulls?q=is%3Apr+is%3Aclosed) and corresponding [initial pull request for German translation](https://github.com/github/opensource.guide/pull/577) on this repository. You can also [add collaborators to your fork](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository) if you'd like to invite other translators to commit directly to your fork and share responsibility for merging pull requests.
+Completing an initial translation of the whole site is a fairly large task. One way to break that task up is to work with other translators through pull requests on your fork. Example: [pull requests on fork for German translation](https://github.com/katrinleinweber/opensource.guide/pulls?q=is%3Apr+is%3Aclosed) and corresponding [initial pull request for German translation](https://github.com/github/opensource.guide/pull/577) on this repository. You can also [add collaborators to your fork](https://docs.github.com/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository) if you'd like to invite other translators to commit directly to your fork and share responsibility for merging pull requests.
 
 ## Updating a translation
 

From 06388a793fb5e5777f6f243c324006676cb450af Mon Sep 17 00:00:00 2001
From: Brian <mookwoo84@gmail.com>
Date: Sat, 4 Apr 2026 18:50:52 -0400
Subject: [PATCH 2/2] Fix broken markdown links and replace dead edunham.net
 URL

- Fix space between ] and ( in fr/starting-a-project.md
- Fix extra angle brackets and space in ms/best-practices.md
- Replace broken edunham.net URL with Web Archive URL in all best-practices.md files
---
 _articles/ar/best-practices.md      | 2 +-
 _articles/best-practices.md         | 2 +-
 _articles/bg/best-practices.md      | 2 +-
 _articles/bn/best-practices.md      | 2 +-
 _articles/de/best-practices.md      | 2 +-
 _articles/el/best-practices.md      | 2 +-
 _articles/es/best-practices.md      | 2 +-
 _articles/fa/best-practices.md      | 2 +-
 _articles/fr/best-practices.md      | 2 +-
 _articles/fr/starting-a-project.md  | 2 +-
 _articles/hi/best-practices.md      | 2 +-
 _articles/hu/best-practices.md      | 2 +-
 _articles/id/best-practices.md      | 2 +-
 _articles/it/best-practices.md      | 2 +-
 _articles/ja/best-practices.md      | 2 +-
 _articles/ko/best-practices.md      | 2 +-
 _articles/ms/best-practices.md      | 4 ++--
 _articles/nl/best-practices.md      | 2 +-
 _articles/pcm/best-practices.md     | 2 +-
 _articles/pl/best-practices.md      | 2 +-
 _articles/pt/best-practices.md      | 2 +-
 _articles/ro/best-practices.md      | 2 +-
 _articles/ru/best-practices.md      | 2 +-
 _articles/sw/best-practices.md      | 2 +-
 _articles/ta/best-practices.md      | 2 +-
 _articles/tr/best-practices.md      | 2 +-
 _articles/zh-hans/best-practices.md | 2 +-
 _articles/zh-hant/best-practices.md | 2 +-
 28 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/_articles/ar/best-practices.md b/_articles/ar/best-practices.md
index 31ff31a05a0..20674f2297f 100644
--- a/_articles/ar/best-practices.md
+++ b/_articles/ar/best-practices.md
@@ -227,7 +227,7 @@ related:
   أنا أؤمن بأن tests ضرورية لكل code يعمل عليه الناس. فلو كان code صحيحًا وكاملًا تمامًا، لما احتاج إلى أي تعديل – نحن نكتب code فقط عندما يكون هناك خلل، سواء كان سببًا في It crashes أو لغياب ميزة معينة .
   وبغض النظر عن التغييرات، تظل tests أساسية لاكتشاف أي regressions قد تدخلها عن طريق الخطأ
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 360d8235fc4..f5283c0de72 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -223,7 +223,7 @@ If you add tests, make sure to explain how they work in your CONTRIBUTING file.
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md
index 8ddd7f1cde4..c3795313da9 100644
--- a/_articles/bg/best-practices.md
+++ b/_articles/bg/best-practices.md
@@ -222,7 +222,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Мисля, че тестването е необходимо за целия код, върху който хората работят. Ако кодът беше напълно и перфектно правилен, нямаше да има нужда от промени - ние пишем код само когато нещо е правилно. грешно, или "Той се срива", или "Тази или онази функция липсва". Каквито и промени да правите, тестването е от съществено значение за улавяне на всякакви регресии, които може случайно да въведете.
   <p markdown="1" class="pquote-credit">
-— @edunham, [Общностна автоматизация на Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, [Общностна автоматизация на Rust"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/bn/best-practices.md b/_articles/bn/best-practices.md
index 9d0ecccf082..bd0e9b8f6a6 100644
--- a/_articles/bn/best-practices.md
+++ b/_articles/bn/best-practices.md
@@ -225,7 +225,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   আমি বিশ্বাস করি যে সকল কোডের উপর মানুষ কাজ করে তার জন্য পরীক্ষা অপরিহার্য। যদি কোডটি সম্পূর্ণ এবং নিখুঁতভাবে সঠিক হত, তাহলে এতে পরিবর্তনের প্রয়োজন হত না - আমরা কেবল তখনই কোড লিখি যখন কিছু ভুল হয়, তা সে "এটি ক্র্যাশ" হোক বা "এটিতে অমুক-অমুক বৈশিষ্ট্যের অভাব রয়েছে"। এবং আপনি যে পরিবর্তনই করুন না কেন, আপনার ভুলক্রমে প্রবর্তিত যেকোনো রিগ্রেশন ধরার জন্য পরীক্ষাগুলি অপরিহার্য।
   <p markdown="1" class="pquote-credit">
-— @edunham, ["রাস্টের কমিউনিটি অটোমেশন"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["রাস্টের কমিউনিটি অটোমেশন"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md
index 3f95f252ee6..6490e056542 100644
--- a/_articles/de/best-practices.md
+++ b/_articles/de/best-practices.md
@@ -253,7 +253,7 @@ Wenn Sie Tests hinzufügen, erklären Sie deren Funktionsweise in Ihrer CONTRIBU
   _I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce._
 
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index 7bd19e2e0e1..136a6cbc897 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -223,7 +223,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Πιστεύω ότι οι δοκιμές είναι απαραίτητες για όλο τον κώδικα που δουλεύουν οι άνθρωποι. Αν ο κώδικας ήταν πλήρως και απόλυτα σωστός, δεν θα χρειαζόταν αλλαγές - γράφουμε κώδικα μόνο όταν κάτι είναι λάθος, είτε αυτό σημαίνει ότι "Καταρρέει" είτε ότι "Του λείπει το τάδε χαρακτηριστικό". Και ανεξαρτήτως των αλλαγών που κάνετε, οι δοκιμές είναι απαραίτητες για να πιάνετε τυχόν παλινδρομήσεις που μπορεί να εισαγάγετε κατά λάθος.
   <p markdown="1" class="pquote-credit">
-- @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+- @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md
index 1c84265b6f7..cd48ef3da02 100644
--- a/_articles/es/best-practices.md
+++ b/_articles/es/best-practices.md
@@ -222,7 +222,7 @@ Si agregas testing, aseg&uacute;rate de explicar c&oacute;mo funcionan en su arc
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Creo que las pruebas son necesarias para todo c&oacute;digo en el que la gente trabaja. Si el c&oacute;digo era totalmente y perfectamente correcto, no necesitar&iacute;a cambios - s&oacute;lo escribimos c&oacute;digo cuando algo est&aacute; mal, ya sea "Se bloquea" o "Falta tal o cual caracter&iacute;stica". Independientemente de los cambios que est&eacute;s haciendo, las pruebas son esenciales para capturar cualquier regresi&oacute;n que pueda introducir accidentalmente.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Automatizaci&oacute;n de la comunidad de Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Automatizaci&oacute;n de la comunidad de Rust"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index ea08d7c3727..34ad4a2a550 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -223,7 +223,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   من معتقد هستم که تست‌ها برای همه‌ی کدهایی که افراد روی آن‌‌ها کار می‌کنند، لازم است. اگر کد کاملاً صحیح و سالم باشد، دیگر نیازی به تغییر نخواهد داشت - ما فقط درصورتی که مشکلی پیش آمده باشد کد می‌نویسیم؛ مگر در زمان‌هایی که کد «خراب شود» یا «فاقد فلان ویژگی باشد». و صرف نظر از تغییراتی که ایجاد می‌کنید، تست‌ها برای دستیابی به رگرسیون‌هایی که به طور تصادفی به وجود می‌آ‌ورید، ضروری است.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md
index 23380b8cb81..2a3318b50cb 100644
--- a/_articles/fr/best-practices.md
+++ b/_articles/fr/best-practices.md
@@ -221,7 +221,7 @@ Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dan
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Je crois que des tests sont nécessaires pour tout le code sur lequel les gens travaillent. Si le code était complet et parfaitement correct, il n'aurait pas besoin de modifications - nous n'écrivons du code que lorsque quelque chose ne va pas, que ce soit "Il plante" ou "Il manque telle ou telle fonctionnalité". Et quels que soient les changements que vous effectuez, les tests sont essentiels pour détecter les régressions que vous pourriez introduire accidentellement.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index c7737a7cb0f..fd15a452a10 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -262,7 +262,7 @@ Il n'est pas nécessaire d'écrire un guide de style pour votre projet lorsque v
 
 ## Votre checklist de pr&eacute;-lancement
 
-Prêt à lancer votre projet open source ? Voici une checklist pour vous aider. Toutes les cases sont cochées ? Vous êtes prêt à vous lancer ! [Cliquez sur "Publier"] (https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) et donnez vous une tape dans le dos.
+Prêt à lancer votre projet open source ? Voici une checklist pour vous aider. Toutes les cases sont cochées ? Vous êtes prêt à vous lancer ! [Cliquez sur "Publier"](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) et donnez vous une tape dans le dos.
 
 **Documentation**
 
diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md
index 2b9a730710e..db75ddb1077 100644
--- a/_articles/hi/best-practices.md
+++ b/_articles/hi/best-practices.md
@@ -224,7 +224,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   मेरा मानना ​​है कि उन सभी कोड के लिए परीक्षण आवश्यक हैं जिन पर लोग काम करते हैं। यदि कोड पूरी तरह से और पूरी तरह से सही था, तो इसमें बदलाव की आवश्यकता नहीं होगी - हम केवल तभी कोड लिखते हैं जब कुछ गलत होता है, चाहे वह "यह क्रैश हो जाता है" या "इसमें ऐसी और ऐसी सुविधा का अभाव है"। और चाहे आप जो भी बदलाव कर रहे हों, आपके द्वारा गलती से पेश किए गए किसी भी प्रतिगमन को पकड़ने के लिए परीक्षण आवश्यक हैं।
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust का सामुदायिक स्वचालन"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust का सामुदायिक स्वचालन"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md
index 091831ba203..a9b3823e38f 100644
--- a/_articles/hu/best-practices.md
+++ b/_articles/hu/best-practices.md
@@ -223,7 +223,7 @@ Ha teszteket adsz hozzá, akkor bizonyosodj meg arról, hogy elmagyaráztad azt
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Úgy gondolom, hogy tesztek szükségesek minden olyan kódhoz, amelyen az emberek dolgoznak. Ha a kód teljesen és tökéletesen helyes volt, akkor nem lenne szükség változtatásokra - csak akkor írunk kódot, ha valami nincs rendben, legyen az összeomlás vagy hiányzó funkció. És függetlenül attól, hogy milyen változtatásokat hajtunk végre, a tesztek elengedhetetlenek a véletlenszerűen bevezetett regressziós hibák kivédésében.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["A Rust közösségi automatizálása"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["A Rust közösségi automatizálása"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md
index f97b2691ca1..123488977d3 100644
--- a/_articles/id/best-practices.md
+++ b/_articles/id/best-practices.md
@@ -221,7 +221,7 @@ Jika Anda menambahkan pengujian, pastikan untuk menjelaskan bagaimana mereka bek
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Saya percaya bahwa pengujian otomatis sangat diperlukan untuk semua kode yang dikerjakan orang-orang.  Jika kode tersebut benar, maka tidak diperlukan perubahan - kita hanya menuliskan kode apabila terjadi kesalahan, apakah "crash" atau "kurang fitur". Tanpa memperhatikan perubahan yang Anda lakukan, pengujian otomatis sangatlah penting untuk menangkap regresi kesalahan yang mungkin Anda timbulkan.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md
index addb535eb28..3b9456beb78 100644
--- a/_articles/it/best-practices.md
+++ b/_articles/it/best-practices.md
@@ -222,7 +222,7 @@ Se aggiungi test, assicurati di spiegare come funzionano nel tuo file CONTRIBUTI
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Penso che i test siano necessari per tutto il codice su cui le persone lavorano. Se il codice fosse completamente e perfettamente corretto, non ci sarebbe bisogno di modifiche: scriviamo il codice solo quando qualcosa è corretto. sbagliato, oppure "Si blocca", oppure "Manca questa o quella funzione". Qualunque sia la modifica apportata, il test è essenziale per individuare eventuali regressioni che potresti introdurre accidentalmente.
   <p markdown="1" class="pquote-credit">
-— @edunham, [Automazione comunitaria di Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, [Automazione comunitaria di Rust"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md
index 3891efcb7cb..46dd8658320 100644
--- a/_articles/ja/best-practices.md
+++ b/_articles/ja/best-practices.md
@@ -221,7 +221,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   私は人々が実装するあらゆるコードに対してテストが必要だと思っています。もしコードが完全に正しいのであれば、変更の必要はありませんが、 私達がコードを書くときは何かがおかしいときです、それは「クラッシュする」であったり「これこれの機能が足りない」といったようなケースです。どんな変更をしようとしているのであれ、テストは誤ってバグを入れ込んでしまう事を防ぐために非常に重要です。
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md
index 75c2c7b92f5..09e1805632f 100644
--- a/_articles/ko/best-practices.md
+++ b/_articles/ko/best-practices.md
@@ -221,7 +221,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust’s Community Automation”](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust’s Community Automation”](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index d5db33cff65..2df5623c707 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -215,7 +215,7 @@ Salah satu cara terpenting untuk mengautomasikan projek anda adalah dengan menam
 
 Ujian membantu penyumbang merasa yakin bahawa mereka tidak akan merosakkan apa-apa. Mereka juga memudahkan anda menyemak dan menerima sumbangan dengan cepat. Semakin responsif anda, semakin aktif komuniti anda.
 
-Sediakan ujian automatik yang akan dijalankan pada semua sumbangan yang masuk, dan pastikan ujian anda dapat dijalankan dengan mudah secara tempatan oleh penyumbang. Wajibkan semua sumbangan kod lulus ujian anda sebelum dapat dihantar. Anda akan membantu menetapkan standard kualiti minimum untuk semua penyerahan. [Pemeriksaan status yang diperlukan] (<https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging>) di GitHub dapat membantu memastikan tiada perubahan digabungkan tanpa ujian anda lulus.
+Sediakan ujian automatik yang akan dijalankan pada semua sumbangan yang masuk, dan pastikan ujian anda dapat dijalankan dengan mudah secara tempatan oleh penyumbang. Wajibkan semua sumbangan kod lulus ujian anda sebelum dapat dihantar. Anda akan membantu menetapkan standard kualiti minimum untuk semua penyerahan. [Pemeriksaan status yang diperlukan](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) di GitHub dapat membantu memastikan tiada perubahan digabungkan tanpa ujian anda lulus.
 
 Sekiranya anda menambahkan ujian, pastikan untuk menerangkan bagaimana ia berfungsi dalam fail CONTRIBUTING anda.
 
@@ -223,7 +223,7 @@ Sekiranya anda menambahkan ujian, pastikan untuk menerangkan bagaimana ia berfun
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Saya percaya bahawa ujian diperlukan untuk semua kod yang diusahakan oleh orang lain. Sekiranya kodnya betul dan betul, ia tidak memerlukan perubahan - kami hanya menulis kod apabila ada yang tidak kena, sama ada "Ia rosak" atau "Tidak mempunyai ciri seperti itu". Dan tanpa mengira perubahan yang anda buat, ujian sangat penting untuk mengatasi kemunduran yang mungkin anda buat secara tidak sengaja.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index 999a9fe71b1..d58f3667d3d 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -239,7 +239,7 @@ Als u tests toevoegt, leg dan uit hoe ze werken in uw CONTRIBUTING-bestand.
   _I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce._
 
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's gemeenschapsautomatisering"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's gemeenschapsautomatisering"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/pcm/best-practices.md b/_articles/pcm/best-practices.md
index cdb25ab028b..dabaf9d91a9 100644
--- a/_articles/pcm/best-practices.md
+++ b/_articles/pcm/best-practices.md
@@ -203,7 +203,7 @@ If you add tests, make sure say you explain how them dey work for your CONTRIBUT
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md
index 773501fa907..afd60ed9f87 100644
--- a/_articles/pl/best-practices.md
+++ b/_articles/pl/best-practices.md
@@ -228,7 +228,7 @@ Jeśli dodasz testy, wyjaśnij, jak działają w pliku CONTRIBUTING.
   <i>
   I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce.</i>
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md
index c168825df3a..cf699cdb1d1 100644
--- a/_articles/pt/best-practices.md
+++ b/_articles/pt/best-practices.md
@@ -221,7 +221,7 @@ Se você adicionar testes, tenha certeza de ter explicado como eles funcionam em
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Eu acredito que testes são necessários em todos os códigos que as pessoas trabalharam. Se o código estivesse completo e perfeitamente correto, ele não precisaria de alterações - nós só escrevemos código quando algo está errado, ou seja "Ele falha" ou "Ele não possui tal recurso". E, independentemente das mudanças que você esteja fazendo, os testes são essenciais para detectar qualquer regressão que você possa introduzir acidentalmente.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md
index 3088b078fde..06c576159d9 100644
--- a/_articles/ro/best-practices.md
+++ b/_articles/ro/best-practices.md
@@ -269,7 +269,7 @@ Dacă adaugi teste, asigură-te că explici cum funcționează în fișierul tă
     </em>
   </p>
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index 372f5b95d3f..1e10f15d5df 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -223,7 +223,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Я считаю, что тесты необходимы для всего кода, над которым работают люди. Если бы код был полностью и совершенно правильным, он не нуждался бы в изменениях — мы пишем код только тогда, когда с ним что-то не так, например, обнаружен баг или отсутствует нереализованная функциональность. И независимо от того, какие изменения вы вносите, тесты необходимы для выявления любых регрессий, которые вы можете случайно допустить.
   <p markdown="1" class="pquote-credit">
-- @edunham, [«Автоматизация сообщества Rust»](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+- @edunham, [«Автоматизация сообщества Rust»](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/sw/best-practices.md b/_articles/sw/best-practices.md
index f7cacf4c449..c6fdf2a8064 100644
--- a/_articles/sw/best-practices.md
+++ b/_articles/sw/best-practices.md
@@ -223,7 +223,7 @@ Ukiongeza majaribio, hakikisha umeeleza jinsi yanavyofanya kazi katika faili yak
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Ninaamini kuwa majaribio ni muhimu kwa msimbo zote ambazo watu hufanya kazi. Ikiwa msimbo ulikuwa sahihi kabisa, hautahitaji mabadiliko - tunaandika tu msimbo wakati kuna kitu kibaya, iwe "Inaacha kufanya kazi" au "Haina kipengele fulani-na-vile". Na bila kujali mabadiliko unayofanya, majaribio ni muhimu ili kupata matatizo zozote ambazo unaweza kuanzisha kimakosa.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md
index d96148bc945..a8ddbf02d57 100644
--- a/_articles/ta/best-practices.md
+++ b/_articles/ta/best-practices.md
@@ -221,7 +221,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   மக்கள் வேலை செய்யும் அனைத்து குறியீட்டிற்கும் சோதனைகள் தேவை என்று நான் நம்புகிறேன். குறியீடு முழுமையாக மற்றும் செய்தபின் சரியானதாக இருந்தால், அதில் மாற்றங்கள் தேவையில்லை - ஏதாவது தவறு ஏற்பட்டால், அது "அது செயலிழக்கச் செய்கிறது" அல்லது "இது போன்ற ஒரு அம்சம் இல்லை" என்பதை நாம் மட்டும் குறியீட்டை எழுதலாம். நீங்கள் எடுக்கும் மாற்றங்களைப் பொருட்படுத்தாமல், நீங்கள் தற்செயலாக அறிமுகப்படுத்தக்கூடிய எந்தப் பின்னடைவுகளையும் கையாளுவதற்கு சோதனைகள் அவசியம்.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["ரஸ்ட்'ஸ் சமுதாய தன்னியக்கமாக்கல்"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["ரஸ்ட்'ஸ் சமுதாய தன்னியக்கமாக்கல்"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 2b851214f6d..e9cc11af2a5 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -223,7 +223,7 @@ Testler eklerseniz, CONTRIBUTING dosyanızda nasıl çalıştıklarını açıkl
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   İnsanların üzerinde çalıştığı tüm kodlar için testlerin gerekli olduğuna inanıyorum. Kod tamamen ve tamamen doğru olsaydı, değişikliğe ihtiyaç duymazdı - değişikliklerin yapılması gerektiğine - yalnızca bir şey yanlış olduğunda, "Çöktüğünde" ya da "Böyle ve böyle bir özellikten yoksun" olduğunda kod yazarız. Yaptığınız değişikliklerden bağımsız olarak, testler yanlışlıkla verebileceğiniz herhangi bir zararı yakalamak için gereklidir.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust'un Topluluk Otomasyonu"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust'un Topluluk Otomasyonu"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md
index edc4b09aa07..796f1307286 100644
--- a/_articles/zh-hans/best-practices.md
+++ b/_articles/zh-hans/best-practices.md
@@ -217,7 +217,7 @@ fork 一个项目不什么坏事情。能复制并且修改别人的代码是开
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   我相信测试对所有的代码都是需要的。如果代码被完整的覆盖了测试，以后就不需要改了。我们只需要在代码崩溃或者需要某个功能的添加代码。不管你在修改什么，测试对于检查那些你可能不小心制造的问题都是必须的。
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust 社区的自动化"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust 社区的自动化"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 
diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md
index 91d348b7545..c78592194b6 100644
--- a/_articles/zh-hant/best-practices.md
+++ b/_articles/zh-hant/best-practices.md
@@ -217,7 +217,7 @@ fork一個專案不什麼壞事情。能複製並且修改別人的程式是開
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   我相信測試對所有的程式都是需要的。如果程式被完整的覆蓋了測試，以後就不需要改了。我們只需要在程式崩潰或者需要某個功能的添加程式。不管你在修改什麼，測試對於檢查那些你可能不小心製造的問題都是必須的。
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust 社群的自動化"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust 社群的自動化"](https://web.archive.org/web/20241218114447/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>